[PATCH 07/12] hotplug: Modify OdevAttributes for server-managed fd support

Dave Airlie airlied at gmail.com
Tue Jan 28 13:29:20 PST 2014

On Tue, Jan 28, 2014 at 6:49 PM, Hans de Goede <hdegoede at redhat.com> wrote:
> Hi,
> On 01/28/2014 08:01 AM, Dave Airlie wrote:
>> On 16 Jan 2014 00:33, "Hans de Goede" <hdegoede at redhat.com> wrote:
>>> With systemd-logind support, the xserver, rather then the drivers will be
>>> responsible for opening/closing the fd for drm nodes.
>>> The initial open will happen on probe from config/udev.c, this commit adds
>>> a fd member to OdevAttributes to store the fd to pass it along to the
>> driver.
>>> The server_fd and paused flags are added to indicate wether server-
>>> managed fds are in use for this device, and if they are if the device is
>>> paused (no drm master rights) or not.
>>> This commit also bumps the video ABI major, as this constitutes an ABI
>> change.
>>> systemd-logind tracks devices by their chardev major + minor numbers,
>> since
>>> we are breaking ABI anyways also add major and minor fields for easy
>> storage /
>>> retreival of these, as well as a utility function for getting a platform
>>> device by devnum.
>> I'm on a bus but surely you should be adding new attributes not stick them
>> in the attribute list head equivalent?
> The problem is that currently OdevAttributes can only be strings. I cab
> add config_odev_add_attribute_int / xf86_get_platform_device_attrib_int
> functions and make this regular attributes instead if you would prefer
> that ?
> I see 2 ways to handle this:
> 1) Add a type field to struct OdevAttribute and make the
> xf86_get_platform_device_attrib fail for attributes with type of int,
> xf86_get_platform_device_attrib_int fail for non int attributes, and store
> the int directly in the struct
> 2) Convert the int to a string on store and back on retrieval.
> I would prefer method 1, but if you prefer method 2 please let me know before
> I implement this :)

1 seems fine, and I'd prefer that to just putting things directly in
the structure,
which is meant to be independent of underlying OS specifics.


More information about the xorg-devel mailing list