On Thu, Oct 18, 2012 at 09:40:11AM +1000, Dave Airlie wrote:
> On Thu, Oct 18, 2012 at 9:15 AM, Aaron Plattner <[email protected]> wrote:
> > On 10/17/2012 04:12 PM, Peter Hutterer wrote:
> >>
> >> On Wed, Oct 17, 2012 at 03:02:53PM -0700, Aaron Plattner wrote:
> >>>
> >>> If the udev device corresponding to a platform drm device has an
> >>> "xorg_drivers"
> >>> property associated with it, treat that as a comma-separated list of
> >>> driver
> >>> suggestions to use. Otherwise, fall back to the existing PCI ID table.
> >>>
> >>> This lets people create a udev rule to associate an X driver with a given
> >>> drm
> >>> device using rules that look like this:
> >>>
> >>> SUBSYSTEM=="drm", DRIVERS=="i915", ENV{xorg_drivers}="intel"
> >>>
> >>> Signed-off-by: Aaron Plattner <[email protected]>
> >>
> >>
> >> we had a similar suggestion for input drivers when we added udev support.
> >> but to keep the xorg configuration in X, we then added InputClass and
> >> xorg.conf.d snippets. With this patch, you'd have xorg configuration in
> >> udev. Is this really what you want, or is it worth investigating
> >> VideoClass
> >> support?
> >
> >
> > Hmm, maybe. That would be a lot more work, but might be more flexible in
> > the long run. I'll see if I can find some time to work on that.
>
> Though I'm not sure we really VideoClass type situations, we generally
> have a real driver or fallback to modesetting per set of devices.
>
> we don't really have the synaptics situation where one driver can
> drive loads of non-synaptics.
Except evdev, we generally don't use "catchall classes". wacom and synaptics
only get applied for such devices, the rest of the InputClass features is
overloading configurations. e.g. for a product of this name, set that
option. I think this is quite similar to what would apply here.
The above example Aaron gave would be something like
Section "VideoClass"
Identifier "blah"
MatchDRMDriver "i915"
Driver "intel"
EndSection
Cheers,
Peter
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
