Plane helpers and a new plane options ioctl

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Here are the utility functions again. Rebased and updated slightly.

I adapted drm_framebuffer_check() to handle multiple handles, and I changed
some of the error values it returns.

The plane options ioctl is a bit of an open question. I started by adding
separate ioctls for some subsets of the fucntionality, but then I was just
writing so much duplicated ioctl handling code that I decided it doesn't
seem right. I'm not really happy with this monster ioctl either.

I would actually like to replace the whole KMS API with some tag-length-value
(TLV) type of thing. Basically you'd just feed the ioctl a KMS object ID and
bunch of attribute IDs + values. The ioctl could take multiple such "streams"
for any number of KMS objects.

It would be easily extendible simply by adding new types of attributes.

It would also support atomic mode setting changes across an arbitrary set
of KMS objects, without having to do some kind begin+set+set+set...+commit
multi ioctl sequence with all the state management nightmares that it would
entail.

It would also cleanly handle cases where some attributes would be somehow
tied together in hardware (eg. you have to set one attribute to a specific
value, before another atribute can be set). With a multi ioctl approach you
would have to accept invalid intermediate states, and delay error checking
until the commit ioctl.

Of course you'd need to parse the "stream" and feed the resulting state to
the driver somehow. I'm think the common code would pass the stream to the
driver attribute at a time, and the driver would build up the state, possibly
doing some early error checking. Finally when the whole state is built up,
it would would be passed to the driver for final error checking, and if
everything looks good the driver could push the state to the hardware. The
driver could then attempt to do its thing in an atomic fashion, if possible.

Well, that's my utopian idea. Would require quite a bit of work though.
Anyone else thinking along similar lines?
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux