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

[Dave Airlie]

>>
>> 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.

Well this code is for addressing hotplug eventually, the code is all
written to do it,
just doesn't make sense until I finish lots of other bits. The thing
is if I don't know
what the OS-specific info that needs to go from udev<->driver via the xf86 DDX,
I can't abstract it. For input we've all but just made this
information udev/evdev and Linux
info, with no guarantee that other OSes could use it. So maybe I can
just pretend I'm being
OS friendly and remove the name udev.


>> We'd of course need better naming for BUS_UDEV then?
>
>
> I was thinking BUS_PLATFORM.  Blue.  No, yellow.

Yeah I could live with that.

>
> 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.

Yeah virtual drivers need old-skool probe.

>> 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?

Ease of migrating the drivers is probably top of the list,
pointless-ness of doing hotplug on
non-KMS drivers. I don't mind doing simple automatic API tweaks in
drivers, but I'm not
really wanting to do in depth surgery in order to support hotplug on
the 5 or drivers I care about.

The current v3 plan is to have one ScreenRec/ScrnInfoRec per protocol
screen, with linkages
to one ScreenRec/ScrnInfoRec per hotplugable driver. These structures
for now would remain
the same as otherwise I don't think it'll ever get merged. So we
continue to have screenInfo.screens
and xf86Screens containing arrays of the "protocol" screens. Then
screenInfo.gpuscreens and
xf86GPUScreens arrays containing the hotpluggable screens.

If a driver doesn't support hotplug then it acts like it does now, we
have one ScreenRec
protocol/gpu combined screen. If a driver supports hotplug then we
create one protocol ScreenRec
and one GPU ScreenRec. If someone plugs in a device and the main
driver is a single
ScreenRec nothing happens, if someone plugs in a device and the main
driver is hotplug
capable we'll create another GPU screen rec and attach it in the
correct place, depending
on what type of slave it its initially, and once shatter works better,
it can be its own rendering
master.

>> 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.

But we need to bind to headless devices for PRIME to work on GPUs with
no outputs.


>>> 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.

Primary is also used on the switchable GPU laptops to denote who is running
the show, like whether Intel should be running the show with nouveau
as an offload slave
or nouveau running the show with intel as an output slave.

>
> Heh.  To me that sounds like incentive.  I have an almost reasonable idea of
> how that code works, I just hate it.

Some bits of xf86pciBus.c seem like stuff I'd rather not know,
MatchPciInstances is the
main, seems like a lot of code for whatever its doing.

>> 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.
>

Well fglrx doesn't require a kernel driver still, again this might change,
fglrx still uses old Probe paths anyways, it never even grew pciaccess.

I suppose I could blend the pci probe into the udev probe, but again I don't
really care for hotplug on non-kms/non-udev since nobody from those areas
cares enough to do the work. Like if nvidia or ATI want to propose enhancements
to the udev code so they can work with this stuff I'd be happy to
review/add them,
Its the same as evdev on Linux being out defacto input standard, I'd rather just
state KMS is the defacto output standard interface.

Dave.