On Tue, Jan 28, 2014 at 6:49 PM, Hans de Goede <[email protected]> wrote: > Hi, > > On 01/28/2014 08:01 AM, Dave Airlie wrote: >> On 16 Jan 2014 00:33, "Hans de Goede" <[email protected]> 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. Dave. _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
