On 5/8/12 2:12 PM, Dave Airlie wrote:
On Tue, May 8, 2012 at 6:54 PM, Adam Jackson <[email protected]> wrote:
The big thing I don't really like about this patch is how it talks about
udev so much. The driver hook should be platformProbe or osProbe or
something instead, and the fact that it's udev on Linux is just an OS
detail.
Well the problem is I've no idea what hotplug on any other OS is going
to look like,
and I really don't want to invent an abstraction without input from
either someone
a) who cares about another OS
b) has time to help me now, not in 6 months.
Well, okay, but there's two things here. You have config/udev growing
the ability to plug output devices, and you have hw/xfree86 growing a
new device enumeration method during initial config. You're not
_actually_ addressing hotplug yet, you've gotten as far as coldplug.
The thing is we hit drm code in these codepaths and I've no idea if they would
be Linux specific or not, but I suppose I can shift a lot of stuff
into os-support if
necessary.
We'd of course need better naming for BUS_UDEV then?
I was thinking BUS_PLATFORM. Blue. No, yellow.
The probing integrates with the pci probing code and will fallback
to the pci probe and old school probe functions in turn.
What do we need to do to drop the old probe code? XXX DUDE
Like the old code is going to be needed on non-Linux OSes for non-PCI devices,
I've no idea how to make that go away without other OS developers
investing in it.
(other than the remove it all and make them suffer).
Whoops, that XXX was supposed to be me going off and auditing the
drivers and including the results before sending the email. Go me.
The only non-Linux non-PCI driver I know of is wsfb. But there's still
dummy (and maybe nested?), and there's still fbdev, and I guess I don't
have a good idea of how to express those. Hmm. Probably until I do I
can't lobby for dropping the pre-pciaccess probe yet. Withdrawn.
So the "plan" is to have two sets of xf86Screens, and if a driver
support hotplug (it tells the server via a driverfunc call)
you pass it a flag saying it should add a hotplug screen not a
toplevel protocol screen.
Is that just an optimization or is there a semantic difference? Phrased
another way, why are not all screens hotplug screens? Is it just ease
of migrating the drivers?
Well it could pick up headless things, but the drivers should deal
with that in their probe code and fall out. If we ever get to adding
render nodes we'd have to match on those as well at some point.
Yeah, looks like nothing's calling drm_get_minor() that way yet. I
guess my preference was to _not_ bind to render-only nodes at this
level, and start doing that as an EGL-level decision even under X.
No USB support?
I don't think the concept of Primary device applies to a USB connected device,
since we generally use it for insane things like int10 and stuff.
Ah yeah, forgot that context.
But come to that, we could just as well assert that BUS_ODEV simply
requires that the OS have handled POSTing, and not have the notion of
"Primary" defined at all.
I've thought about doing that, but it is too much ripping up of code
that nobody has any idea of how it magically works.
Heh. To me that sounds like incentive. I have an almost reasonable
idea of how that code works, I just hate it.
There is no way to enumerate non-PCI video devices without a list of
them, KMS drivers is the only way to make it all work.
I'm leaving the old probing functions intact for non-Linux and binary
drivers for now, but I could be tempted to rip them out
on Linux, if I added PCI graphics device to the udev probing I suppose.
Well, binary drivers are going to involve a kernel driver. Maybe it
makes sense to think about this as "ask udev about kernel graphics
services" instead of "ask udev about KMS", which would give the
userspace driver a place to hook in.
- ajax
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
