RFC: what to do with ums when the X server is not suid root ?
luto at mit.edu
Mon Jan 20 18:19:30 UTC 2014
On Mon, Jan 20, 2014 at 7:48 AM, Hans de Goede <hdegoede at redhat.com> wrote:
> On 01/20/2014 03:18 PM, Matthew Garrett wrote:
>> On Mon, Jan 20, 2014 at 10:08:01AM +0100, Hans de Goede wrote:
>>> So now it is time to start looking into some of the corner cases, or
>>> rather at
>>> the elephant in the room. What about non-kms drivers. We still have the
>>> driver around as most prominent example, and this is useful for some
>>> cards and for cards which are too new.
>> -mga is probably also still relevant in some small number of cases.
> Don't we've a kms driver for those? Or you mean for mga cards not supported
> the kms driver?
>> We can probably kill -cirrus. That would leave -openchrome, which I think
>> is probably only really relevant for OLPC? What's the situation with the
>> binary nvidia and amd drivers?
> Oh, I completely did not think about the binary drivers yet. Ugh. AFAIK
> are not compatible with kms, so the helper for other ums drivers would just
> the right thing there since there would be no kms capable card to be found
> in /dev.
>>> I would like to not break the vesa driver, while still killing the suid
>>> bit on
>>> the X server.
>> It's probably worth considering whether porting uvesafb to kms would be
>> worthwhile, and then just using -modesetting.
> Yes that is something I was thinking about too, that would be an interesting
> it would make it somewhat harder for people to use binary drivers, but not
Does uvesafb actually work? I submitted a patch to the uvesafb kernel
driver a few months back, and not only is the upstream link  to
the v86d helper dead, but no one on the dri-devel list answered my
request to see if anyone had a copy. Fedora does not appear to
package a copy (at least yum whatprovides '*/v86d' doesn't come up
with anything). This means that I got a patch into upstream drm and
that it's quite possible that no one (or maybe a grand total of one
person) has ever tested.
Or do you mean the older pre-uvesafb driver?
> And then we could simply forget about supporting ums at all I guess.
> devel mailing list
> devel at lists.fedoraproject.org
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
More information about the devel