>> >> 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. _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
