On 19 November 2015 at 15:06, Adam Jackson <[email protected]> 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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
