Hi,
On 01/20/2014 05:09 PM, Matthew Garrett wrote:
On Mon, Jan 20, 2014 at 04:48:55PM +0100, Hans de Goede wrote:
Hi,
On 01/20/2014 03:18 PM, Matthew Garrett wrote:
-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 by
the kms driver?
The KMS driver only supports the g200 cores embedded in some server
chipsets, it doesn't handle real hardware. We've already dropped 3D
support for those chips, though, so it's arguably not of great
importance. The only real difference in functionality by dropping -mga
would be losing multihead support, and I don't think anyone ever made
that work on the UMS driver without the HAL blob.
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 those
are not compatible with kms, so the helper for other ums drivers would just do
the right thing there since there would be no kms capable card to be found in
/dev.
The binary drivers don't need iopl(), so the only real question is
whether they need root for anything else. It may just be permissions on
device nodes, in which case we can probably just special-case them?
Probably. TBH I'm not that interested in the binary drivers I know the nvidia
one
is actually quite decent and it has a lot of users. So I don't want to break
them,
but beyond that my interest stops. I assume they are still not exporting any kms
API to userspace, so the helper I've in mind should just launch X as root for
them
and then things should just keep working. I know lots of shoulds ...
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
approach,
it would make it somewhat harder for people to use binary drivers, but not
impossible.
I don't see it being any harder than the blacklisting of nouveau/radeon
that's already required.
Well that can be done through a config file, this would require doing a chmod
on the Xorg
binary which would need to be redone after every update. This assumes that if
we go the
uvesafb route we completely remove the helper to launch Xorg as root. Then
again as you've
indicated above they may not need root at all and a couple of udev rules to
open the
right /dev/foo nodes to console users might be enough.
And then we could simply forget about supporting ums at all I guess.
That would be certainly be a glorious flying-car future.
Yep, I think it is probably more realistic to go for the helper first though.
I'm going to
send a mail to xorg-devel to see how crazy people there think it is to turn
uvesafb into a
kms driver.
Regards,
Hans
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
