Direct hardware bashing modules (int10 et al) and recent hardware

[Emil Velikov]

On 19 November 2015 at 15:06, Adam Jackson <ajax at nwnk.net> wrote:
> On Thu, 2015-11-19 at 12:07 +0000, Emil Velikov wrote:
>
>> It seems that most of the use-cases are related to the int10 module.
>> To make things even more interesting - when using the Sun/Oracle
>> compiler many additional functions will end up exported relative to
>> gcc built xserver.
>
> That should be fixed, the export list shouldn't vary by compiler.
>
I won't be able to do any of that as I'm short of the said compiler.
There is a small chance that I misread the code, but in any case there
are a way too many _X_EXPORTs in hw/xfree86/common/compiler.h

>> Afaik the int10 module is not used by kms based video drivers, yet I
>> cannot speak about the "legacy" or proprietary ones. I'm curious how
>> people feel about it - do we still have real users for it, would
>> people feel sad to see it go, etc.
>
> You need it for vesa, for posting secondary cards outside of KMS
> setups,
David Hermann's simple drm driver cames to mind. I guess one can
revive it one of these days (I'm not volunteering though)

> and for posting cards at all if they have x86 firmware and
> you're not on an x86 CPU.
>
This is something that I haven't considered. Thanks !

> If the next question is "can't we stop supporting vesa" the answer is
> "I wish".
>
Pretty much what I was thinking, but didn't dare say it out loud.

>> While on the topic a few other modules come to mind - vgahw. vbe,
>
> vesa needs vbe (though vbe and int10 could reasonably be merged into a
> single library).  Most of the non-KMS drivers for PCI hardware use
> vgahw one way or another.
>
>> fbdevhw, ramdac and extensions - dga, tslib. How people feel about
>> those ?
>
> Removing fbdevhw would break mga and r128 and a few others on non-x86.
>
> ramdac is... special.  It would be nice to see the ramdac drivers split
> out to the GPU drivers consuming them, but the rest of it is hardware
> cursor support that ought to remain shared in server.  It'd be nice if
> we didn't have two files named xf86Cursor.c though.
>
> DGA's pretty harmless at this point, and if you remove the extension
> entirely you break a bunch of old games that require it to be there.
>
> The tslib question is really what do we do with kdrive.  Xfake seems
> pretty useless given Xvfb, and the only win for Xfbdev over Xorg+fbdev
> is marginally smaller footprint.  On the other hand Xephyr is a hugely
> important tool, but tslib support in Xephyr doesn't make a lot of
> sense.  Personally I'd like to see the first two removed and tslib
> support dropped.
>
By the "first two" you mean Xfake and Xfbdev, leaving tslib-less
Xephyr around. Is that correct ?

Huge thanks for the comprehensive reply Adam. It all makes sense now :-)

-Emil