| Summary: | Xorg prints version numbers in wrong format for modules compiled for Xorg 6.99 & later | ||
|---|---|---|---|
| Product: | xorg | Reporter: | Alan Coopersmith <alan.coopersmith> |
| Component: | Server/General | Assignee: | Alan Coopersmith <alan.coopersmith> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | high | ||
| Version: | git | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Bug Depends on: | |||
| Bug Blocks: | 1690 | ||
We should be able to handle the old numbers correctly. The 4.0.x macro, for reference, was: #define XF86_VERSION_NUMERIC(major,minor,subminor,beta,alpha) \ ((((((((major << 7) | minor) << 7) | subminor) << 5) | beta) << 5) | alpha) This scheme was only ever used for modules in the 4.0.x series, so it defines a range of values (4 << 24) through (4 << 24 + 1 << 17 - 1) where the version number is "old style". That corresponds to 67108864 through 67239936. In the new numbering scheme that would be 6.71.8.764 through 6.72.39.934. We can safely say that we will never release an X11R6.71 or 6.72, since the end of the R6 series is 6.9. Therefore numbers in that range are unambiguous. I have at least one future project that wants the ability to load 4.0.x modules, so I would like to see us handle the old-style range correctly. Created attachment 3289 [details] [review] CharToUnicode changes trivial fix Created attachment 3290 [details] [review] _mesa wrappers for libc functions this time for sure (<< has lower precedence than +, need more parens) Looks pretty much like the fix I had written but hadn't gotten around to testing
until this evening. (Except I left out the "- 1", figuring it wasn't needed with
the < instead of <= .)
I just tested on the same system that was reporting the 4.22.7H| version numbers,
and it's now reporting:
compiled for 6.99.99.900, module version = 1.2.0
so I'll go ahead and commit.
(I also couldn't find anywhere else this needs to be fixed.)
Fix committed to CVS head: CVSROOT: /cvs/xorg Module name: xc Changes by: alanc@gabe.freedesktop.org 05/08/08 18:18:04 Log message: 2005-08-08 Alan Coopersmith <alan.coopersmith@sun.com> * programs/Xserver/hw/xfree86/loader/loadmod.c Bug #3950 <https://bugs.freedesktop.org/show_bug.cgi?id=3950> Xorg prints version numbers in wrong format for modules compiled for Xorg 6.99 & later (Adam Jackson & Alan Coopersmith) Modified files: xc/programs/Xserver/hw/xfree86/loader/: loadmod.c ./: ChangeLog Revision Changes Path 1.8 +7 -1 xc/programs/Xserver/hw/xfree86/loader/loadmod.c 1.1192 +7 -0 xc/ChangeLog |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
When testing a modular built Xserver, I noticed the module versions in my error log were strange: (II) Module vesa: vendor="X.Org Foundation" compiled for 4.22.7H|, module version = 1.0.0 Checking in the source I found the versions were set right in the modules, as XORG_VERSION_CURRENT had been expanded to the value for 6.99.99.900: ( ( ( 6 ) * 10000000 ) + ( ( 99 ) * 100000 ) + ( ( 99 ) * 1000 ) + 900 ), but the code to print the version number in hw/xfree86/loader/loadmod.c was interpreting it incorrectly, since the resulting value of 69999900 is now greater than (4 << 24), aka 67108864, so it treats it as an XFree86 4.0.x version number and mangles it as shown. We need to decide if we still care about printing correct versions for modules built for XFree86 4.0.x or figure out a way to correctly print those and 6.99/7.x version numbers.