No more 1280x1024 with xorg-x11-drv-geode-2.11.0-1.fc10.i386 Boot up F10-i686-Live-KDE replace /etc/X11/xorg.conf with attached xorg.conf (because hardwired xorg.conf for geode) Leave -> Logout to restart X => Xorg.0.log.geode-2.10.1 Mode 1280x1024 is working as expected yum update xorg-drv-geode restart X => Xorg.0.log.geode-2.11.0 Mode 1280x1024 no longer working In Xorg.0.log.geode-2.10.1 is this: (II) GEODE(0): Printing DDC gathered Modelines: (II) GEODE(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz) In Xorg.0.log.geode-2.11.0 is this: (II) GEODE(0): Printing probed modes for output default (II) GEODE(0): Modeline "1028x1024"x60.0 108.00 1028 1328 1440 1688 1024 1025 1028 1066 -hsync -vsync (64.0 kHz) Can 1028 be a typo of 1280?
Created attachment 21502 [details] Used xorg.conf
Created attachment 21503 [details] Xorg.0.log.geode-2.10.1 of working driver
Created attachment 21504 [details] Xorg.0.log.geode-2.11.0 of nonworking driver
because off no response till now I downloaded xf86-video-geode-2.11.0.tar.gz and did a grep for 1028. in lx_panel.c I found this code-snippet DisplayModeRec lx_panel_modes[] = { {MODEPREFIX, 31200, 320, 354, 384, 400, 0, 240, 249, 253, 260, 0, V_NHSYNC | V_NVSYNC, MODESUFFIX} , /* 320x200@75 */ {MODEPREFIX, 25175, 640, 656, 744, 800, 0, 480, 490, 492, 525, 0, V_NHSYNC | V_NVSYNC, MODESUFFIX} , /* 640x480@60 */ {MODEPREFIX, 40000, 800, 840, 968, 1056, 0, 600, 601, 605, 628, 0, V_NHSYNC | V_NVSYNC, MODESUFFIX} , /* 880x600@60 */ {MODEPREFIX, 65000, 1024, 1048, 1184, 1344, 0, 768, 771, 777, 806, 0, V_NHSYNC | V_NVSYNC, MODESUFFIX} , /* 1024x768@60 */ {MODEPREFIX, 81600, 1152, 1216, 1336, 1520, 0, 864, 865, 868, 895, 0, V_NHSYNC | V_NVSYNC, MODESUFFIX} , /* 1152x864@60 */ {MODEPREFIX, 108000, 1028, 1328, 1440, 1688, 0, 1024, 1025, 1028, 1066, 0, V_NHSYNC | V_NVSYNC, MODESUFFIX} , /* 1280x1024@60 */ {MODEPREFIX, 162000, 1600, 1664, 1856, 2160, 0, 1200, 1201, 1204, 1250, 0, V_NHSYNC | V_NVSYNC, MODESUFFIX} , /* 1600x100@60 */ }; by logical comparing the entries there are possible typos DisplayModeRec lx_panel_modes[] = { {MODEPREFIX, 31200, 320, 354, 384, 400, 0, 240, 249, 253, 260, 0, V_NHSYNC | V_NVSYNC, MODESUFFIX} , /* 320x200@75 */ --------------------------------------------------^^ possible typo, should be mayby 60 {MODEPREFIX, 25175, 640, 656, 744, 800, 0, 480, 490, 492, 525, 0, V_NHSYNC | V_NVSYNC, MODESUFFIX} , /* 640x480@60 */ {MODEPREFIX, 40000, 800, 840, 968, 1056, 0, 600, 601, 605, 628, 0, V_NHSYNC | V_NVSYNC, MODESUFFIX} , /* 880x600@60 */ {MODEPREFIX, 65000, 1024, 1048, 1184, 1344, 0, 768, 771, 777, 806, 0, V_NHSYNC | V_NVSYNC, MODESUFFIX} , /* 1024x768@60 */ {MODEPREFIX, 81600, 1152, 1216, 1336, 1520, 0, 864, 865, 868, 895, 0, V_NHSYNC | V_NVSYNC, MODESUFFIX} , /* 1152x864@60 */ {MODEPREFIX, 108000, 1028, 1328, 1440, 1688, 0, 1024, 1025, 1028, 1066, 0, -------------------------^^^^ possible critical typo, should be mayby 1280 V_NHSYNC | V_NVSYNC, MODESUFFIX} , /* 1280x1024@60 */ {MODEPREFIX, 162000, 1600, 1664, 1856, 2160, 0, 1200, 1201, 1204, 1250, 0, V_NHSYNC | V_NVSYNC, MODESUFFIX} , /* 1600x100@60 */ -----------------------------------------------^^^ possible typo, should be mayby 1200 }; I am a stupid user and not knowing what I am doing, so can please a developer confirm my observations?
Had the same issue when going from 2.10.1 to 2.11.3 - It seems the way to configure modelines for panels was changed. You now need to add the modeline for the panel in the DEVICE section as: -- Option "PanelMode" "108000 1280 1328 1440 1688 1024 1025 1028 1066" -- instead of a Modeline in the MONITOR section.
Does this bug still apply to Geode 2.11.9 or not?
Created attachment 38236 [details] Desktop snapshot with autodetected mode This bug does still apply to Geode 2.11.9 See attachment: "Desktop snapshot with autodetected mode" for reference.
A patch for this typo error has been commmitted. Can we close this issue? http://cgit.freedesktop.org/xorg/driver/xf86-video-geode/commit/?id=becaa0ae375e996c2f83192bb84a5c89f94933dd Thanks, Frank
Yes, we can close it, since the fix has been committed to GIT.
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.