Bugzilla – Bug 310305
sax2: cannot (re)write xorg.conf
Last modified: 2008-04-07 15:35:25 UTC
After applying the patch to correct the evdev issue sax2 and sax2 -r is used, sax2 refuses to generate new updated xorg.conf. Even if xorg.conf is removed a new one is never generated. It seems like that no probing is done of the hardware after the patch was applied. The patch fix in question can be found in Bug 262317
Since only users with exactly one mouse model from Logitech would be affected by this problem - they aren't any longer since we no longer use evdev driver (profile) for them - this is definitely not a blocker for openSUSE 10.3. It should be investigated for openSUSE 11.0. This is correct.
> The patch fix in question can be found in Bug 262317 Comment #43. This hunk. --- /usr/share/sax/profile/logitech-Gaming.orig +++ /usr/share/sax/profile/logitech-Gaming @@ -1,10 +1,11 @@ +!remove InputDevice -> [X] -> Option -> Name !remove InputDevice -> [X] -> Option -> Device +!remove InputDevice -> [X] -> Option -> Protocol InputDevice -> [X] -> Identifier = Mouse[[X]] InputDevice -> [X] -> Driver = evdev -InputDevice -> [X] -> Option -> Protocol = event -InputDevice -> [X] -> Option -> InputFashion = Mouse -InputDevice -> [X] -> Option -> Name = Logitech USB Receiver InputDevice -> [X] -> Option -> SendCoreEvents = on InputDevice -> [X] -> Option -> ZAxisMapping = 4 5 InputDevice -> [X] -> Option -> Buttons = 20 +InputDevice -> [X] -> Option -> Vendor = 0x046d +InputDevice -> [X] -> Option -> Product = 0xc041
Well because after applying the patch sax2 then refuses to generate any xorg.conf no matter what mouse is plugged in it effects a larger range of products. I would say thishas to be fixed in 10.3.
This is a wrong assumption. The patch changes 3 profiles. One (for your mouse) has been disabled. The other 2 profiles are used for Logitech MediaPlay (works for me) and Logitech MX Laser mouse (no problematic report up to now).
Very well, is there a update yet on the update server yet to see if the disabling of evdev with the updated profiles actually cures the sax2 issue of not writing a xorg.conf yet? I am willing to do yet another reinstall with the the "evdev-free" updates and see if sax2 now generates a changable xorg.conf. If not can we get rebuilt packages up on the update server before openSUSE 10.3 RC 1 release?
http://download.opensuse.org/repositories/xorg73/openSUSE_Factory/ --> sax2-ident
Sadly that repo will work for the 10.3 B 3 as it has a bug in determining freedisk space when a repo like that is added. The only way I would be able to test it out would be if it was in the suse updates.
Not sure, why you want to add the repo. Just download and install the RPM. http://download.opensuse.org/repositories/xorg73/openSUSE_Factory/i586/sax2-ident-8.1-370.1.i586.rpm http://download.opensuse.org/repositories/xorg73/openSUSE_Factory/x86_64/sax2-ident-8.1-370.1.x86_64.rpm
* Stefan could you check if the patch really works for you ? * I had a look at this patch and I think there could be problems with it +!remove InputDevice -> [X] -> Option -> Name !remove InputDevice -> [X] -> Option -> Device +!remove InputDevice -> [X] -> Option -> Protocol ===> why is protocol removed ? InputDevice -> [X] -> Identifier = Mouse[[X]] InputDevice -> [X] -> Driver = evdev -InputDevice -> [X] -> Option -> Protocol = event -InputDevice -> [X] -> Option -> InputFashion = Mouse ===> That's not good, InputFashion is a sax internal identifier specifying the kind of the input device If you remove it sax is not able to configure this section and so the changes there will be lost as soon as you configure something with the sax gui. Why is that removed it's just an option evdev shouldn't handle X simply ignores options it can't handle. -InputDevice -> [X] -> Option -> Name = Logitech USB Receiver ===> also not a good idea, without a Name no information can be displayed in the gui. I think you never checked that patch while loading the configuration into the sax2 gui InputDevice -> [X] -> Option -> SendCoreEvents = on InputDevice -> [X] -> Option -> ZAxisMapping = 4 5 InputDevice -> [X] -> Option -> Buttons = 20 +InputDevice -> [X] -> Option -> Vendor = 0x046d +InputDevice -> [X] -> Option -> Product = 0xc041 ====> From my perspective this is the only relevant change concerning the evdev driver so why did your patch remove all the other information ? Please double check Thanks
"Not sure, why you want to add the repo. Just download and install the RPM." Simply for the reason to verify that sax2 is not ran before the inital setup failure. Just installing the rpms still results in no xorg.conf created even with the new rpms. Whatever the patch exposes for either new or old bugs it seems once the "patched" edition of the package is installed the damage is already irreversably done to sax2.
" ===> That's not good, InputFashion is a sax internal identifier specifying the kind of the input device If you remove it sax is not able to configure this section and so the changes there will be lost as soon as you configure something with the sax gui. Why is that removed it's just an option evdev shouldn't handle X simply ignores options it can't handle." Can we please mark this as a duplicate bug of the original bug in which the patch was implemented in as you seemed to have hit the nail on the head with the issues involved with the patch. This should be reverted back to the original Bug 262317 and remarked as Blocker on it.
*** This bug has been marked as a duplicate of bug 262317 ***
No, I don't want to handle this as a blocker. I prefer to work on this one.
(In reply to comment #13 from Stefan Dirsch) > No, I don't want to handle this as a blocker. I prefer to work on this one. s/blocker/duplicate
The patch removes Name option since it has a completely different meaning for evdev driver than for other input drivers (see man evdev). If this option is required for SaX2 we need to rename this option in the evdev driver. Protocol and InputFashion options were removed since these are not mentioned in evdev manual page. I didn't know that InputFashion is a sax internal identifier. Protocol option could be a general input driver option. Proposal: - rename "Name" option in evdev driver - add Protocol and InputFashion again (X only complained about wrong use of Name option) - Vendor/Product options are added as before
> The patch removes Name option since it has a completely different meaning > for evdev driver than for other input drivers (see man evdev). If this > option is required for SaX2 we need to rename this option in the evdev > driver. Sorry, I mixed this up with "vendor" option. But there was also something wrong when option "Name" is set (see Bug #262317, comment #108). I need to (re)figure out what ...
> (X only complained about wrong use of Name option) This was "vendor" option.
Dean, the output of "cat /proc/bus/input/devices |grep Name" could help here to see if it's different to "Logitech USB Receiver".
Output of "cat /proc/bus/input/devices |grep Name" for old Logitech G5 is I: Bus=0003 Vendor=046d Product=c041 Version=0111 N: Name="Logitech USB Gaming Mouse"
Ok. So that's different from what SaX expected and would explain, why it was a bad idea to set this option.
Created attachment 172753 [details] evdev-ontop.diff This one has to be applied on top of the old patch #1 (Bug #262317, comment #43). Description: - no longer remove "Protocol"/"Name" options - set "Protocol" option to "event" again - set internal SaX2 option "InputFashion" to "Mouse" again - set "Name" option again (changed it for logitech-Gaming mouse from "Logitech USB Receiver" to "Logitech USB Gaming Mouse") - enables logitech-Gaming profile again
I just talked to Marcus and we agreed that Vendor/Product options are not required, if Name option is set correctly, which obviously was not the case. I'll attach a new patch.
Created attachment 172764 [details] evdev-ontop.diff
Thanks Stefan this looks really good now. Will submit a package now
Created attachment 172776 [details] sax2-ident-8.1-248.i586.rpm
Created attachment 172777 [details] sax2-ident-8.1-248.x86_64.rpm
I've attached packages for testing. Feedback will be appreciated.
Just been testing sax2-ident-8.1-248.x86_64.rpm and it works fine for me. The xorg.conf file can be updated. Both commands 'sax2' and 'sax2 -r' are working. If xorg.conf doesn't exist, sax2 creates a new one with repeating the following warning six times: ISaX: Could not import file: /var/cache/sax/files/config at /usr/sbin/isax line 199 As far as I can see, all seems fine ;-)
Thanks for testing!
The new x64 rpm still does not work for me. Behavior is the same with ISaX: Could not import file: /var/cache/sax/files/config at /usr/sbin/isax line 199 but no new xorg is generated at all. I will try a reinstall of the system yet again as I had already upgraded the system to openSUSE 10.3 (X86-64) Beta3plus.
So maybe the output of "cat /proc/bus/input/devices |grep Name" on your machine is different? (I didn't recognize that the feedback (comment #19) to this question (comment #18) came from Thomas and not from you.) So we fixed it for Thomas and broke it for you?
The is the exact and complete output of "cat /proc/bus/input/devices |grep Name" linux:~ # cat /proc/bus/input/devices |grep Name N: Name="PC Speaker" N: Name="Logitech USB Gaming Mouse" N: Name="Logitech Logitech Gaming Keyboard" N: Name="Logitech Logitech Gaming Keyboard" N: Name="G15 Keyboard G15 Keyboard" N: Name="Power Button (FF)" N: Name="Power Button (CM)" linux:~ # "So we fixed it for Thomas and broke it for you?" Well it remains broke. Just did a fresh clean install with the Beta 3 DVD and installed the rpm the exact same results. No new xorg.conf written.
I should add 'sax2' and 'sax2 -r' makes no difference. No xorg.conf is written.
> N: Name="Logitech USB Gaming Mouse" Looks fine. > Well it remains broke. Just did a fresh clean install with the Beta 3 DVD and > installed the rpm the exact same results. No new xorg.conf written. Could you at least attach /var/log/SaX.log?
Created attachment 172845 [details] SaX.log here is the sax.log of what happens after the updated rpm is applied on a fresh install.
Thanks! Hopefully Marcus can figure out what's still wrong here ...
I sure hope he can I have 265 machines spec'd out with the same configs awaiting the upgrades. For me, this is a show blocker.
Marcus, could you have a look at the SaX.log? Otherwise I'm afraid we're back to disable the profile for this mouse.
I had also a look at the SaX.log of Dean, and according to it the mouse is up and working. The log looks quite similar to mine. Only the 'select returned 0' / '1' sequence differs a bit. Come to think about it, I once had a firmware upgrade on the mouse - but this shouldn't influence in any way. Dean, have you tried to select a lower screen resolution to see whether xorg.conf gets written or not?
Yes, I have tried selecting the lower resolutions as well. Still no xorg written. Concerning the firmware upgrade to the mouse, I too have applied it but that was only last week in an attempt to see if it would resolve anything. The firmware upgrade made no difference.
as a side note, after nvidia's blob's have been installed, nvidia-xconfig makes a working xorg.conf but sax2 remains unusable. Just for comparison I'll post it. # nvidia-xconfig: X configuration file generated by nvidia-xconfig # nvidia-xconfig: version 1.0 (buildmeister@builder26) Wed Jun 13 16:54:14 PDT 2007 Section "ServerLayout" Identifier "Layout0" Screen 0 "Screen0" InputDevice "Keyboard0" "CoreKeyboard" InputDevice "Mouse0" "CorePointer" EndSection Section "Files" RgbPath "/usr/lib64/X11/rgb" EndSection Section "Module" Load "dbe" Load "extmod" Load "type1" Load "freetype" Load "glx" EndSection Section "InputDevice" # generated from default Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/psaux" Option "Emulate3Buttons" "no" Option "ZAxisMapping" "4 5" EndSection Section "InputDevice" # generated from default Identifier "Keyboard0" Driver "kbd" EndSection Section "Monitor" Identifier "Monitor0" VendorName "Unknown" ModelName "Unknown" HorizSync 30.0 - 110.0 VertRefresh 50.0 - 150.0 Option "DPMS" EndSection Section "Device" Identifier "Device0" Driver "nvidia" VendorName "NVIDIA Corporation" EndSection Section "Screen" Identifier "Screen0" Device "Device0" Monitor "Monitor0" DefaultDepth 24 SubSection "Display" Depth 24 Modes "1600x1200" "1280x1024" "1024x768" "800x600" "640x480" EndSubSection EndSection
Dean, could you *please* remove the xorg.conf files written by nvidia-xconfig before you do any tests? Thanks.
Another important test. Remove the line "0x046d : 0xc041 : logitech-Gaming" in /usr/share/sax/sysp/maps/ Input.map and post the results. This will give me some important information. Do not forget to attach /var/log/SaX.log.
Created attachment 172919 [details] xorg.conf Beta3plus (In reply to comment #42 from Stefan Dirsch) > Dean, could you *please* remove the xorg.conf files written by nvidia-xconfig > before you do any tests? Thanks. > I always do. I was just posting the xorg.conf written by nvidia-xconfig showing what does work. Non of my issues have been reported using anything but the base install. Upon further investigation, the MX510 does indeed set the correct metamodes upon initial installation if it is used BUT subsequent sax2 sessions write no xorg.conf nor do they pickup the correct metamodes for the monitor. The G5 does not as sax fails upon writing the initial config. So in summary, Fresh install with a MX510 results in the initial successful xorg.conf but any changes through sax2 fail to write a xorg.conf Fresh install with a G5 results in a immediate failure to write a working xorg.conf because of the evdev bug, and sax2 cannot launch. After patching for the G5, sax2 will launch but still does not detect the correct metamodes nor save a xorg.conf. Sooooo after discovering that I then did a fresh web installs of openSUSE 10.3 (X86-64) Beta3plus with the G5 attached. This time upon first attempt to boot to the desktop the monitor starts in a endless loop of attempts to sync with the monitor, you could see the x of the cursor pop up for a second and then it would try again to resync. So I reboot start at runlevel 3 and apply your patches. Good news is that sax2 will again launch after applying the patches but still will not write a xorg.conf. Now what I used to do before is keep a known good xorg.conf laying around and just copy it over to /etc/X11/xorg.conf which was the only way of me getting a functional desktop before. Figuring this would work as well with Beta3plus I did the same thing and copied it over. The result though this time was quite different. Even with the known good xorg.conf in place X still refused to launch. I could never get to the desktop even as I made one final stab at the cat with installing the nvidia blobs and tried using their nvidia-xconfig with the same results. This is really getting me puzzled. The next step I did was once again do another install but this time swapping out the video card for another nvidia series (5200) and replaced the monitor with another multisync crt of different brand and make (Hyundai Deluxscan 5870). The results with the different card and monitor were the EXACTLY the same. I've now done a total of 8 reinstalls since I last posted with different combinations of crt monitors, videocards (even switched heads on the cards as a stab in the dark), motherboards, installation media, patched and unpatched all failing except at least with the Beta3 ISO and previous I could at least copy over a known good xorg.conf and get to the desktop even though sax2 was completely useless. I do believe your latest G5 patches are working at least because after applying them sax2 will at least launch but again it just refuses to write a new xorg.conf. Can someone please do me the favor of trying with the fully patched sax2-ident to save a new xorg.conf while using a multisyc crt monitor? For what it is worth I will attached the xorg that was generated by the installer with Beta3plus.
(In reply to comment #43 from Stefan Dirsch) > Another important test. Remove the line "0x046d : 0xc041 : logitech-Gaming" > in /usr/share/sax/sysp/maps/Input.map and post the results. This will give > me some important information. Do not forget to attach /var/log/SaX.log. So did you already try this? Can sax2 afterwards write an initial config?
>For what it is worth I will attached the xorg that was generated by the >installer with Beta3plus. On Beta3+ sax2 used the "mouse" instead of the "evdev" driver for the G5 mouse. I still don't understand why SaX2 can't write an initial xorg.conf with G5 in place, but since it also can't rewrite it with a MX510 in place (which does not use evdev at all), this is likely a completely unrelated issue you are observing.
The configuration looks valid and functional to me. If you want this mouse to be configured with evdev you need to provide the information from sysp -q mouse and if possible the required evdev configuration in order to allow me to create a profile for that mouse Anyway I agree with Stefan's last comment
As I have the same mouse as Dean, I think I can also provide some info. # sysp -q mouse Mouse0 => Protocol : explorerps/2 Mouse0 => Device : /dev/input/mice Mouse0 => Buttons : 12 Mouse0 => Wheel : 2 Mouse0 => Emulate : 0 Mouse0 => Name : Logitech USB Gaming Mouse Mouse0 => VendorID : 0x046d Mouse0 => DeviceID : 0xc041 Mouse0 => Profile : logitech-Gaming Mouse0 => RealDevice : /dev/input/by-id/usb-Logitech_USB_Gaming_Mouse-mouse Mouse0 => NutShell : 0
And here's my current InputDevice section of /etc/X11/xorg.conf : Section "InputDevice" Driver "evdev" Identifier "Mouse[1]" Option "Buttons" "20" Option "InputFashion" "Mouse" Option "Name" "Logitech USB Gaming Mouse" Option "Protocol" "event" Option "SendCoreEvents" "on" Option "Vendor" "Sysp" Option "ZAxisMapping" "4 5" EndSection
(In reply of comment #44 from Dean Hilkewich) >Sooooo after discovering that I then did a fresh web installs of openSUSE 10.3 >(X86-64) Beta3plus with the G5 attached. This time upon first attempt to boot >to the desktop the monitor starts in a endless loop of attempts to sync with >the monitor, [...] If your attached xorg.conf Beta3plus was the used configuration for this behaviour, then evdev & G5 haven't anything to do with it, because it uses the old classical mouse setup. Also please don't forget comment #43 From Stefan Dirsch.
I will try all your suggestions when I get back from work today which should be in about 11 hours.
Unfortunately, it looks like I won't be able to perform the reinstalls tonight as it seems that the factory mirrors are in a state of brokeness with missing suse/setup/descr/packages. Perhaps tomorrow.
With RC1 coming out tomorrow, I will do fresh installs with the RC1 DVD to update this issue.
Well unfortunately, RC1 brings a whole new set of problems that prevents me from even getting to sax, upon the second stage, right after the reboot of the install after the installation of the packages yast freaks out with a bus error and drops you to the text login awaiting for a login which is not possible as not even the root account has been setup. This is the first time since starting with Suse 8, that I have had this many issues. It seems as the release progresses, issues get worse.
I'm hoping they can resolve this issue and put out another RC quickly as it seems there are a lot of people with this issue even with the live CD's judging by the feedback on forums and seems to effect AGP users.
Dean, please open a separate bugreport for the problem you mention in comments #54 and #55. Thanks, Andreas
Created attachment 174081 [details] Initial Xorg.conf after completing Stage 2 of install. Andreas, the initial login issue seems to have resolved itself when updates to the NTP service is disabled AND the filesystem is XFS. Switching to EXT3 and disabling the NTP service resolves that issue which I believe has already been cured in recent patches. Once that was sorted out (by formatting to EXT3 and disabling NTP) I was able to successfully complete the second stage of install, but alas Sax still does not work right. After the initial xorg.conf is written in stage 2, xorg does boot up but timing issues with multisyc CRT's still are there (scrambled video out upon first boot to desktop) and Sax still refuses to give a complete resolution settings. I no longer think this is a result of evdev but is a bug that just appeared after the evdev bug was cured with patching (although the left and right are reversed on tilt wheel with evdev). The sax2 generated xorg (attachment xorg.conf.initialstage2) results in a scrambled screen because of timings. Then when a reboot to init 3 is done and a sax2 -r is done it gives a xorg.conf file that is completely wrong in metamodes and subsequent runnings of sax2 changes no enteries nor writes a new xorg.conf file. (attachment xorg.conf.sax) A handmade xorg.conf will work fine (attachment xorg.conf.works) but even that does not allow sax to recreate a new xorg.conf when ran and still does not allow proper resolution selection in sax2.
Dean, can you provide the info requested in comment #47 ?
Mouse0 => Protocol : explorerps/2 Mouse0 => Device : /dev/input/mice Mouse0 => Buttons : 12 Mouse0 => Wheel : 2 Mouse0 => Emulate : 0 Mouse0 => Name : Logitech USB Gaming Mouse Mouse0 => VendorID : 0x046d Mouse0 => DeviceID : 0xc041 Mouse0 => Profile : logitech-Gaming Mouse0 => RealDevice : /dev/input/by-id/usb-Logitech_USB_Gaming_Mouse-mouse Mouse0 => NutShell : 0
Here are more bug reports with the same issue. https://bugzilla.novell.com/show_bug.cgi?id=327171 https://bugzilla.novell.com/show_bug.cgi?id=327299 https://bugzilla.novell.com/show_bug.cgi?id=327499
I don't think the issues you're seing and mentioning are related to the use of evdev at all.
As I've said in previous posts that I no longer think it's a evdev bug anymore as well but a bug that could not be exposed before because the evdev bug was blocking the discovery of this new one. "I no longer think this is a result of evdev but is a bug that just appeared after the evdev bug was cured with patching (although the left and right are reversed on tilt wheel with evdev)." "I do believe your latest G5 patches are working at least because after applying them sax2 will at least launch but again it just refuses to write a new xorg.conf."
(In reply to comment #57 from Dean Hilkewich) > ... I was able to successfully complete the second stage of install, > but alas Sax still does not work right. After the initial xorg.conf is > written in stage 2, xorg does boot up but timing issues with multisyc CRT's > still are there (scrambled video out upon first boot to desktop) and Sax > still refuses to give a complete resolution settings. I no longer think this > is a result of evdev but is a bug that just appeared after the evdev bug was > cured with patching (although the left and right are reversed on tilt wheel > with evdev). > > The sax2 generated xorg (attachment xorg.conf.initialstage2) results in a > scrambled screen because of timings. This is a configuration for a 1600x1200 resolution. > Then when a reboot to init 3 is done and a sax2 -r is done it gives a > xorg.conf file that is completely wrong in metamodes and subsequent runnings > of sax2 changes no enteries nor writes a new xorg.conf file. (attachment > xorg.conf.sax) No Metamodes in there. Just Modelines for 1280x1024 and below. Default resolution is 1280x1024. > A handmade xorg.conf will work fine (attachment xorg.conf.works) but even > that does not allow sax to recreate a new xorg.conf when ran and still does > not allow proper resolution selection in sax2. No resolution given at all in this config. [...] HorizSync 30.0 - 110.0 VertRefresh 50.0 - 150.0 You can be lucky you got the right resolution with acceptable timings. BTW, I don't know your preferred resolution. And there are no logfiles attached either.
Created attachment 174383 [details] xorg99 and Sax logs (In reply to comment #63 from Stefan Dirsch) > (In reply to comment #57 from Dean Hilkewich) > This is a configuration for a 1600x1200 resolution. Yes but the modelines are completely out of whack. > No Metamodes in there. Just Modelines for 1280x1024 and below. Default > resolution is 1280x1024. Sorry I did mean modeslines, default is set to 1280x1024 but cannot be changed at all with sax. Previous releases of opensuse allowed me to select 1600x1200 which is the preferred setting > No resolution given at all in this config. > > [...] > HorizSync 30.0 - 110.0 > VertRefresh 50.0 - 150.0 > > You can be lucky you got the right resolution with acceptable timings. BTW, I > don't know your preferred resolution. And there are no logfiles attached > either. > Then I've been lucky on many machines as timings are dead on every system I have tried with this xorg.conf with a full range of working resolutions from 320x240 to 1600x1200. Auto-select has worked perfectly on every machine tested. If attaching of logs is what you wish then a updated delta iso for the dvd's is required as I'm not willing to do multiple reinstalls anymore as the PITA factor of not being able to easy continue to stage 2 of the install with the current RC1 iso release. Here are my xorg99 and sax log. Yes, I am now using the nvidia blob but it is not a nvidia blob issue as it's the same results with the nv driver.
I think it would be a good idea to summarize what the remaining issues of this bug are. I completely lost the overview. The summary should be adjusted as well.
Summary The sax2 generated xorg (attachment xorg.conf.initialstage2) results in a scrambled screen because of timings. Then when a reboot to init 3 is done and a sax2 -r is done it gives a xorg.conf file that is completely wrong in modelines and subsequent runnings of sax2 changes no enteries nor writes a new xorg.conf file. (attachment xorg.conf.sax) A handmade xorg.conf will work fine (attachment xorg.conf.works) but even that does not allow sax to recreate a new xorg.conf when ran and still does not allow proper resolution selection in sax2.
[Created at monitor.94] Unique ID: jyhG.57wnV4KUCJ6 Hardware Class: monitor Model: "COMPAQ P700" Vendor: CPQ "COMPAQ" Device: eisa 0x1351 "COMPAQ P700" Serial ID: "034CA45VB566" Resolution: 720x400@70Hz Resolution: 720x400@88Hz Resolution: 640x480@60Hz Resolution: 640x480@67Hz Resolution: 640x480@72Hz Resolution: 640x480@75Hz Resolution: 800x600@56Hz Resolution: 800x600@60Hz Resolution: 800x600@72Hz Resolution: 800x600@75Hz Resolution: 832x624@75Hz Resolution: 1024x768@87Hz (interlaced) Resolution: 1024x768@60Hz Resolution: 1024x768@70Hz Resolution: 1024x768@75Hz Resolution: 1280x1024@75Hz Resolution: 640x480@85Hz Resolution: 800x600@85Hz Resolution: 1024x768@85Hz Resolution: 1152x864@75Hz Resolution: 640x350@60Hz Size: 320x230 mm Detailed Timings #0: Resolution: 640x350 Horizontal: 640 672 736 832 (+32 +96 +192) -hsync Vertical: 350 382 385 445 (+32 +35 +95) +vsync Frequencies: 31.50 MHz, 37.86 kHz, 85.08 Hz Driver Info #0: Max. Resolution: 1280x1024 Vert. Sync Range: 48-120 Hz Hor. Sync Range: 30-92 kHz Bandwidth: 31 MHz Config Status: cfg=new, avail=yes, need=no, active=unknown That's the output of hwinfo --monitor
So is this now a "will not fix"? Sorry to sound pushy but I have to make my final recommendations to the school board tomorrow. I'd love to stick with suse but this is a blocker for us.
I can't comment on the "cannot (re)write xorg.conf" issue, but the "nv: wrong frequencies" issue seems to be a duplicate of Bug #328939. SaX2 should not create any modelines, since nv driver uses the NoModelines profile. BTW, there are two entries in Driver.map for nv driver as you can see. :-( I also don't understand why nv uses the NVidia profile ... # /.../ # Mapping table for X11 driver to profile # ===================================================== # Driver Name | Profile # ----------------------------------------------------- nv : Depth24,NVidia nvidia : Depth24,NVidia radeon : Depth24,Radeon i810 : Depth24,NoDDC,LinearAlloc sis : SiS,Depth24 fglrx : FireGL tseng : VideoRAM intel : Depth24,Intel nv : NoModelines fbdev : NoModelines
OK thank you for your attempts. Hopefully this can be corrected for opensuse 11 so we can switch back opensuse in the future. Unfortunately that means we have to switch to Fedora 8 this semester as it does not exhibit the same issues.
Created attachment 176313 [details] Complete set of x11 and sax logs Here is a complete set of logs using 10.3 Final. Issue remains the same.
The issues in comment #69 are fixed. Adjusting summary.
Dean, in case openSUSE is still an option for you and your students, please reevaluate if the remaining issue ("sax2 cannot (re)write xorg.conf") still occurs with openSUSE 11.0. Thanks. Schedule for openSUSE 11.0: http://en.opensuse.org/Roadmap
Stefan, the issue has been fixed in a update since the goldmaster was released (which specific patch it is I don't know). My current work around is that I have to add the update repo and the nvidia repo to the additional sources during the 1 stage of install, then everything goes smooth. I've since remastered the DVD to automatically add the update repo as a install source. As far as us switching back to openSUSE, I will have to re-evaluate it, currently there are too many show stoppers for me to say right now such as https://bugzilla.novell.com/show_bug.cgi?id=371657, https://bugzilla.novell.com/show_bug.cgi?id=350017, and having to rebuild the Nvidia rpms manually to test with openSUSE 11 since none are provided for the development releases.
Sounds fair enough. Thanks for considering switching back to openSUSE. Since the remaining issue has been fixed meanwhile, I think it's appropriate to close this bugreport as as well. Thanks for your patience!