veyepar: Botching up IOCTLs

State:
Locked:	clear this to unlock
Locked by:	user/process that locked.
Start:	initially scheduled time from master, adjusted to match reality
Duration:	length in hh:mm:ss
Name:	Video Title (shows in video search results)
Emails:	email(s) of the presenter(s)
Released:	has someone authorised pubication
Normalise:
Channelcopy:	m=mono, 01=copy left to right, 10=right to left, 00=ignore.
Thumbnail:	filename.png
Description:	One clear insight kernel graphics hackers gained in the past few years is that trying to come up with a unified interface to manage the execution units and memory on completely different GPUs is a futile effort. So nowadays every driver has its own set of ioctls to allocate memory and submit work to the GPU. Which is nice, since there's no more insanity in the form of fake-generic, but actually only used-once interfaces. But the clear downside is that there's much more potential to screw things up. To avoid repeating all the same mistakes again this talk will present some of the lessons learned while botching the job for the drm subsystem in general and the i915 driver specifically. Topics covered will be the bare basic to avoid needless busywork later on, reasonable minimal testing to avoid CVEs and other embarrassement. And generally a thicket of war stories to figure out what works and where's still some white spots in the userspace interface landscape. markdown
Comment:	production notes

2015-01-16/15_39_12.dv Apply: 15:39:12 - 16:26:00 ( 00:46:48 ) S: 15:39:12 - E: 16:26:00 D: 00:46:48 show more...

vlc ~/Videos/veyepar/lca/lca_2015/dv/Case_Room_2/2015-01-16/15_39_12.dv :start-time=00.0 --audio-desync=0

Rf filename:	root is .../show/dv/location/, example: 2013-03-13/13:13:30.dv
Sequence:
get this:	check and save to add this