| Summary: | xf86-video-geode crashes on start since 2.11.x when DDC/UART mux is in UART mode | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Mart Raudsepp <leio> | ||||||
| Component: | Driver/geode | Assignee: | Xorg Project Team <xorg-team> | ||||||
| Status: | RESOLVED MOVED | QA Contact: | Xorg Project Team <xorg-team> | ||||||
| Severity: | normal | ||||||||
| Priority: | medium | CC: | connor.behan | ||||||
| Version: | unspecified | ||||||||
| Hardware: | Other | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| i915 platform: | i915 features: | ||||||||
| Attachments: |
|
||||||||
|
Description
Mart Raudsepp
2009-06-04 17:29:20 UTC
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.