Hi,
On 01/21/2014 12:57 PM, David Herrmann wrote:
Hi
On Tue, Jan 21, 2014 at 9:36 AM, Hans de Goede <[email protected]> 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
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
