[PATCH 2/2] xfree86: use udev to provide device enumeration for kms devices

[Adam Jackson]

On 5/8/12 2:12 PM, Dave Airlie wrote:
> On Tue, May 8, 2012 at 6:54 PM, Adam Jackson <ajax at nwnk.net> 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