Since the RANDR1.2 port in xf86-video-geode-2.11 the driver crashes on X.org startup immediately if the firmware has set up the DDC/UART muxed GPIO to serial port (UART) mode. Before there was code made to detect the GPIO mode and not do any DDC queries if it is in serial port mode. But while that checking still exists and the fact that it is in UART mode gets reported in Xorg.0.log, DDC calls are still made through RANDR impementation vfunc regardless of that, and Xorg crashes on the results that gets to in UART mode. This bug is the primary reason 2.11 is not packaged in Gentoo Linux yet, as it breaks things for my own geode platform development :(
A workaround is Option "NoDDC" in xorg.conf. Probably just need to add some checks in the right place of the randr1.2 interface implementation to not call into EDID xserver code when we have figured out we are in serial mode. (and 2.11 series has been packaged in gentoo for quite a long while now)
Does this bug still apply to Geode 2.11.9 or not?
AMD might be willing to fix this, since this involves a standard Geode feature, but additional details might need to be provided to this bug report.
One solution could be to make our driver bit-bang the GPIO into DDC mode, early in the driver startup pahse, to ensure that DDC probing will always work.
The crash only happens on LX hardware.
LX hardware happens to be the majority of what's left of the Geode market.
I have two still widely used US-made POS machines with this Geode LX chip. At least one of them actually makes use of the multiplexed DDC/UART2 gpio line for the serial connected touchscreen. If/when the KMS driver gets included in the kernel, can we have a way to use both DDC control and UART2? E.g. switching to DDC only momentarily while initializing the Geode video and allow the UART2 most of the time?
Created attachment 120261 [details] [review] Possible fix A bit lower brow than the proposal to always get DDC working.
Thanks for the patch. This does a fair job of avoiding an explicit crash whenever DDC is unavailable. When that happens, restricting available modes to those that AMD considers safe i.e. Panel-friendly modes, is indeed a promising strategy. However, that strategy doesn't guarantee that the selected mode is something that the connected VGA monitor can handle. It's a shot in the dark and the mode we try, 1920x1440, is a large enough size (and an uncommon enough resolution) that we cannot consider that shot in the dark to be a safe one. Thinking out loud, 800x600, 1024x768 or 1280x1024 would probably be safer modes to attempt whenever DDC is unavailable, pretty much in that order.
Created attachment 121450 [details] [review] Improved fix You're right. The panel resolution would usually be too big for an external display. This new patch picks the largest mode mentioned in xorg.conf if anything is there. Otherwise it uses those three modes with a preference for 800x600.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-geode/issues/2.
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.