Re: further issues with MGA G200 graphics chipset

[Jocelyn Falempe <jfalempe@redhat.com>]

On 24/04/2026 08:20, Thomas Zimmermann wrote:
> Hi
> 
> Am 23.04.26 um 21:42 schrieb Jacob Keller:
> [...]
>> Unfortunately, I also have no better idea than a DMI quirk table to
>> record known platforms that include the controller but don't have a
>> physical VGA connection exposed.
> 
> I'm in favor of this. If you send a meaningful DMI identifier for your 
> system, I'd make you a patch for testing.

I didn't find something related to VGA connector in dmidecode.
My suggestion would be to use the chassis-type [1], and disable polling 
on Blade (0x1C and 0x1D) and Rack Mount (0x17) as they are less likely 
to have a real VGA monitor connected.
My Dell T310, which is kind of a Tower, has a chassis-type of 0x11 "Main 
server chassis" so it might not be very reliable.

Another option would be to disable polling if PREEMPT_RT is set, so if 
the user expects low latency, he can actually have it.

Last resort is that the driver did work for 2 decades without polling 
the VGA connector, maybe we can revert to that behavior.

-- 

Jocelyn

[1] 
https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.9.0.pdf

> 
> I don't know of any way for detecting the presence of a physical VGA 
> connector BTW.
> 
> Best regards
> Thomas
> 
>>
>> Thus, I'm wondering what else we can do? Using WQ_UNBOUND might help
>> somewhat? I have no idea if its safe to sleep instead of spin while
>> reading the i2c connections... As far as I can tell the non-atomic
>> version has nothing that *strictly* prevents sleep.. but maybe i2c
>> access has tighter timing requirements than what usleep_range can
>> fulfill? I am not sure...
>>
>> I'd just really like to not have to worry about going to every single
>> user and asking them to unload and ban a driver for these big server
>> platforms...
>