http://bugzilla.novell.com/show_bug.cgi?id=470341 http://bugzilla.novell.com/show_bug.cgi?id=470341#c49 --- Comment #49 from andreas bittner <abittner@stud.fh-heilbronn.de> 2009-11-23 21:17:15 UTC --- doesnt help either. even with ps2 keyboard only and no usb attached devices at all, the X -logverbose 7 process never reacts to any keypresses or anything. i can only kill it signal 1 doesnt help, only signal 9 (kill -9) kills the process the logfile is only 30kbytes in size then, and the whole log part when the X process shuts down is missing ofcourse, the other logs i generated on that machine (when the xorg.conf files where still there) were much larger (90kbytes or something) during an X -logverbose 7 and cltr+alt+bacspace (after a few secs) session. but maybe those were the additional usb keyboard and whatnot devices..... who knows. any more hints? or should i then create my other bugreport for the hd4200 (according to wikipedia its an rv620 chipset, and its barely different from many other rv610 chipsets which were still the radeon 3xxx line (also some firegl, mobility etc chipsets are rv620 based), so i am really really wondering if we need a separate bugreport just because its hd4200 which is not that much different from the hd3200 or hd3300 chipsets. the bug seems to behave constantly the same way in the radeonhd driver, no matter what exact chipset of these newer radeon hd igp chipsets are being used. by now i have created most of the 785G (hd 4200) logfiles from the 11.1 testsystem (except for the latest scenarios with the empty/missing xorg.conf ones), so i can provide the logs when its already trying to use the radeonhd driver. when the xorg.conf files are missing, it seems to cycle through all kinds of drivers but ends up in the vesa/framebuffer one as far as i can tell from my understanding, and im not really sure what those logs would actually help. the vesa/framebuffer with X -logverbose 7 from runlevel3 on this machine (this way that the xorg.conf files are gone) is actually the only scenario when the driver outputs the pixels in the real native 1680x1050@60hz (thats what the flatpanel hardware onscreen display says) resolution to my flatpanel screen all other scenarios only produced stuff like 1400x1050 or 1280x1024 so far, and the pixels were outside the screen (towards the left and bottom) funny thing is: the only other place where my hardware onscreen display shows 1680x1050 native resolution is the opensuse splash screen after ther kernel has been loaded (for example from the dvd install media during install time), when the little progess bar is being seen for a while, where you can press escape and see the kernel bootup (dmesg?) logmessages live on the screen. also during booting from the installed screen there is this same splashscreen and its also in native resolution. everything is else has been non-native stuff and more or less messed up, even when sax2 (connected directly via vga cable) actually detected my 1680x1050 resolution and name/vendor of the flatpanel, but never actually switched into the native resolution. the closest i have been seems to be this 1400x1050 (at least thats why hardware flatpanel osd says) when the screen is out of bounds towards lower left. i dont see the startmenu of kde4 in that way any more nor the lower kde4 panel or what thats called. regards. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.