Resurrecting uvesafb and turning it into a kms driver ?

[Alex Deucher]

On Tue, Jan 21, 2014 at 9:15 AM, Hans de Goede <hdegoede at redhat.com> wrote:
> Hi,
>
> On 01/21/2014 12:57 PM, David Herrmann wrote:
>>
>> Hi
>>
>> On Tue, Jan 21, 2014 at 9:36 AM, Hans de Goede <hdegoede at redhat.com>
>> wrote:
>>>
>>> Hi,
>>>
>>> I've started a discussion on fedora-devel about what to do with old-style
>>> userspace mode setting
>>> drivers when the suid root bit is removed from the X server binary:
>>>
>>> https://lists.fedoraproject.org/pipermail/devel/2014-January/194123.html
>>>
>>> I started this discussion there because to me the decision to actually
>>> remove the suid root bit,
>>> and the implications of this wrt supported devices, etc. is mostly a
>>> distro
>>> decision. I assume
>>> we as upstream will keep supporting the suid root + ums way of working
>>> for a
>>> long time yet.
>>>
>>> One interesting remark made in the discussion thread I linked to is to
>>> simply drop support for
>>> ums all together (in Fedora) and ship uvesafb ported to be a kms driver
>>> for
>>> cards which don't
>>> have kms support yet.
>>>
>>> I think this is an interesting approach, so this leads me to the question
>>> how crazy would it
>>> be / how crazy a person would it take to do this. Specifically the
>>> resurrecting uvesafb and
>>> turning it into a kms driver part ?
>>>
>>> And related to this, assuming it is considered doable by a sufficiently
>>> motivated person,
>>> would it be worthwhile ?
>>
>>
>> http://cgit.freedesktop.org/~dvdhrm/linux/log/?h=simpledrm
>>
>> I wrote that like 1 year ago and have been resurrecting it the last
>> week. Unfortunately, I'm quite busy so will not get it ready before
>> FOSDEM, I think. Note that the branch is highly out of date, I changed
>> a lot in my local tree.
>>
>> SimpleDRM is not exactly uvesafb, but it's a driver which would allow
>> an arbitrary backing framebuffer. It can already replace efifb, vesafb
>> and simplefb. Any other fbdev driver would just need a new backend
>> (like 200 lines of code).
>
>
> Hmm, one downside of this would be we would end up with a fixed resolution,
> and I dunno how well vesa plays with edid, if we could guarantee (on proper
> vesa implementations) that we would get the monitors native resolution
> something like this would be acceptable.
>
> Then again, this assumes we set up the vesa mode really early, otherwise
> we need an userspace helper anyways. And doing this really early would
> mean built-in, and I don't think we want that. We want to not use vesa
> unless absolutely necessary, not built it in and enable it by default.
>

Being that the legacy bios is getting replaced with UEFI on most
platforms, is it worth putting a lot of effort into vesa?  Also, even
with vesa you are limited to the mode numbers supported by the vesa
implementation which may not actually correspond to the native mode of
the display.

Alex

>>
>> Does that sound good? Or do you really need the uvesafb functionality.
>> I really dislike the user-space connection.. but if you want it, I
>> also have a bunch of patches here that allow user-space controlled
>> devices which I use for debugging. I can try to prep them for FOSDEM.
>
>
> AFAIK the userspace part is mandatory if you don't want to do the vesa
> bios setup very early on, which we don't. Not to mention that it is needed
> to do vesa on non x86.
>
> I've a feeling that your user-space controlled case works the other way
> around,
> so userspace can create a fixed-res kms card by passing in a framebuffer,
> how it works with uvesafb afaik is that the kernels calls into userspace
> to do some bios work, but everything is kernel initiated. This allows a
> (to be written) kms driver to present all available resolutions to userspace
> and allows userspace to do resolution switching, which is likely useful if
> the vesa EDID support is as bad as I'm afraid it is.
>
> Still simpledrm is an interesting way of dealing with this. I can envision
> instead of going the uvesafb-kms way, having the initrd loading relevant kms
> drivers and if there is no kms device registered after that invoking a
> userspace
> helper which pokes the vesa bios and tells simpledrm here is a linear fb,
> export
> it as a fixed resolution kms device please, and then starting plymouth ...
>
> Lets see what others have to say. Definitely something to discuss at Fosdem.
>
> Regards,
>
> Hans
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel