Resurrecting uvesafb and turning it into a kms driver ?

[Hans de Goede]

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.

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