This is some very early demo code for the atomic modesetting feature.
According to my current plan there would be just one ioctl. You simply feed
it an arbitrary list of object properties and the implementation will decice
how it can apply those (for example, whether it can complete the operation
truly atomically and/or asynchronously). So everything is a property. This
means the ioctl should be able to handle all future requirements just as
long as they can be expressed using properties that fit the current model.
In order to be able to feed connector lists, gamma tables, etc. the ioctl has
to accepts blobs. Just one blob per property for now. Not sure if that would be
enough. I also extended range propeties to support signed values.
The implementation has to provide five function pointers, and the
operation goes roughly like this:
ioctl() {
funcs->begin
for_each_prop
funcs->set
funcs->check
if (!check_only)
funcs->commit
funcs->end
}
The begin function allocates some kind of state object that will be used to
collect all the modified state from all the properties. The approach I used
in the demo implementation is to have the full state contained in the state
object, and then keep modifying it according to the new property values.
Finally the whole state gets checked as an atomic unit, and commited to
hardware if everything is OK.
The demo implementation I included does work, albeit not atomically and it
doesn't actually do any real state checking. It just calls the pre-existing
crtc helper and plane funcs from the commit hook.
I'm still pondering about the error reporting. One crazy idea would be to
return an error value for each modified property. That way the driver could
more accurately inform user space why the state is invalid.
Another missing thing is the completion event support. I'm thinking it
should perhaps just contain one timestamp, that being for the time when
the whole operation has completed. If the user wants accurate per-CRTC
timestamps he'd have to issue separate ioctls. The other approach would
be per-object timestamps. Or should it perhaps send out a separate event
for each modified object?
Also it would be nice if the completion event would contain a list of
framebuffer objects that became available when the operation completed.
That would be useful for triple buffering use, since you can't tell
beforehand which framebuffer gets replaced with the new one when you
issue flips faster than the refresh rate.
Some kind of event cookie could also be nice to have, to associate
each event with the ioctl request that spawned it.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
