Re: further issues with MGA G200 graphics chipset

[Jocelyn Falempe]

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...