Xv2 is a hypothetical family of two updates to support video displaying that isn't Xv.
- Render: Allow dest-only pictures, add YUV formats
- Randr: Add overlay objects beside CRTCs: enable, disable, property mangling, mandatory formats supported and acceptable CRTC mask properties, as well as a 'current backing Picture' property. Drivers wrap Render context creation and set ShmPutImage/Composite to their former Xv paths. Port properties become Randr overlay properties.
Rambling IRC braindump
I should clean this up and summarise, but right now it's here for posterity. Also encompasses server development, future driver API, and future render API discussions.
< ajax> exa is giving me vertigo < daniels> maybe if we do fold the drivers into the server to start smashing up the api, people won't notice drm because it'll still be two steps. win. * daniels draws for the epsom salts. < ajax> i think i'm just going to smash the api and tell people to cope < ajax> doing shatter well essentially requires breaking the ScreenRec < daniels> ajax: i was thinking more along the lines of actually creating an api first. < ajax> daniels: madness. < daniels> as opposed to, y'know, what we have now. < ajax> yeah we should have one of those, shouldn't we. < daniels> if we say in advance that 7.6 + 2.0 are going to be this big break and that master may not always be buildable due to active development, then i think we can more than get away with it. < ajax> i've been hoping to slowly morph towards having something sensible, but i might be losing patience < daniels> ajax: right, but morphing from here to there essentially requires creating an api, no? < ajax> daniels: evolving, but yeah. the advantage being that you don't have to hope you design it right up front < ajax> which we are manifestly shit at < ajax> HI MEMORY MANAGER HOW ARE YOU < daniels> of course there are still renovations like the i2c api of shame, but most of it is going to be fbScreenInit + mangle masks + gamma init + picture init + randr init + create visuals list + OH GOD I DON'T CARE -> xorg_create_a_screen_for_the_love_of_god()) < jcristau> which one? :) < daniels> ajax: oh god no. it comes organically or it comes xkb. < daniels> ajax: but i get the sense that a new api is mostly going to look like a new header file with a whole host of new functions which replace almost all the old functions (and then your mode + video + etc helpers) < ajax> also, you're talking about driver api, and i'm talking about rendering api. they're related but not identical. < daniels> yes, that also. that's not on my immediate hitlist though. < daniels> what did you have in mind? < daniels> (also, our input driver api is, surprisingly crap. need to fix that, and lift a raft of stuff into the dix.) < daniels> InputDriverRec + IDrvRec + maybe DeviceIntRec if you're lucky -> OH GOD NOT THE FACE < ajax> we still expose basically the whole gc/picture/xvctx to the driver. drivers shouldn't have to know about the protocol's semantics, we should be giving them a much smaller rendering task. < daniels> \o/ < daniels> exa isn't tooo bad in that sense though. < ajax> it's better but still not good < ajax> the Picture is a disaster of a struct < daniels> i don't know if you know, but in x terms, that's called a celebration. < ajax> the _one_ thing that the core rendering model got right is that the chalkboard is not the chalk < daniels> the what isn't the what? < ajax> the GC isn't the Drawable < ajax> but in the Picture they're bound together < daniels> yeah, they did get the model right there. < daniels> heh. progress! < daniels> hmm, i should fix up render-arg-reduction if we're breaking this api anyway, because seriously. < daniels> gtkperf got something like 33% in some tests just from fb-internal arg reduction, not even the entire chain. < ajax> render-argh-reduction < daniels> (hi! my name is arm! please don't have 12 arguments for deeply-wrapped functions, because it makes me sad.) < ajax> x86 doesn't like it either, for that matter < ajax> we just hide it with l1 < daniels> sure, but the overall performance penalty isn't so bad. < daniels> right. < daniels> plus a hojillion more cycles per second. < ajax> so yeah. render and xv need proper contexts, and so does the Screen for getimage and possibly the implicit window rendering shit. < ajax> which i'm considering tossing altogether and just forcing CompositeRedirectAutomatic < ajax> (or equivalent semantics) < ajax> i hate the window rendering rules so very hard < daniels> meh, if you're doing that, just add YUV formats to Render and implement Xv as a wrapper for that. < ajax> it's not clear how you keep the overlay fastpath for that < daniels> plus, is there any reason _not_ to force automatic redirection? all the consumer-device kids are getting on compositing (including us), so that's the main argument gone ... < ajax> depends how much memory pressure you're willing to accept, i guess < daniels> ajax: overlay> how not? < daniels> i guess you'd need a way to route to ports, but that gives us a one-extension xv. < daniels> 'bind this render yuv texture to this overlay', which also lets you deassociate. that's grabport and stopvideo in one, and putimage is nothing if not composite dst. < daniels> dberkholz: oh? < dberkholz> on one hand, we're assuming people are running distros by defaulting to black < daniels> s/one-extension/one-request/ < daniels> okay, listports and port properties. blah blah i'm not listening anymore. < daniels> or, wait. randr! aha. every gpu gets some overlays, which can have an acceptable crtc mask. so we punt the hard decisions to the client. win. < daniels> ajax: anyway, so. render gets yuv picture support. randr gets overlays at the same level as crtcs, and behave like them (enable/disable/props), but also have acceptable crtc & format masks. you have one request to bind a picture to a port, and rendering is just composite. sound okay? < ajax> what do you composite _to_? < ajax> i guess have an internal picture type that means "overlay port"? < daniels> well, you've given render a GC, so at context creation time, you set Composite to your overlay path if it's an overlay. < ajax> heh. dest-only picture. yeah, that sounds plausible < marcheu> the major difference between xv and yuv render is the semantics. and we need it to optimize the upload < ajax> you just don't expose that picture type to clients through render < daniels> you even get to use the general fb code, because dst with no mask is easy. if they want to alpha-blend on the client side, they can cop the slow path. < ajax> marcheu: ShmPutImage not enough for you? < ajax> daniels: i guess the one remaining bugbear is "magic encrypted content stream" as a picture format. but that should be fine, just looks like another format. < daniels> marcheu: i don't see how it's a problem if you have shm and you get a say in ctx creation? if it's on an overlay, wrap ->ShmPutImage and ->Composite and set them to your fastpaths. < daniels> ajax: PICT_BULLSHIT32 < marcheu> ajax: getting the best performance is quite card-dependent < daniels> ajax: specified as always passing through unmolested, and any attempt at manipulation fails. < daniels> marcheu: ... and? < daniels> marcheu: i just don't see how this is even remotely different from the Xv api. you could even make it look exactly the same if you wanted. < marcheu> well then you have to keep the xv api, basically < daniels> ... why? < ajax> yeah, i was anticipating leaving Xv in place as the only thing allowed to create dest-only pictures < marcheu> because if you keep the semantics, you might as well keep the api < daniels> marcheu: you _can_ keep the semantics. < ajax> (well, not the only thing, but as an api compat thing it'd be desirable to keep) < daniels> ajax: i don't see how it's too much different from render, where you already have to pay attention to the format, with the exception of some Pictures being dest-only. i mean, the server implementation of Xv would surely be a tiny shim over render, so why do they have to be so different client-side? < daniels> ajax: mm, you can do api compat forever by having libXv just call out to libXv2, though yeah, that doesn't solve this whole client<->server issue. < ajax> i really can't break libXv < ajax> though lord do i wish < marcheu> daniels: I'm saying you have to basically keep the xv implementation driver-side anyway... < daniels> sure, so that can just call out to the new code. nothing saying that libXv has to implement XVIDEO. < marcheu> yeah, but that's duplication < daniels> marcheu: true for overlays, but it probably means a lot _less_ duplication for textured video. < ajax> daniels: there's a small "hard problem" around making sure the XV object types exist in the protocol somewhere and can be passed around between clients, just in case someone did that. < daniels> ajax: hmm? < ajax> daniels: it's legal to get an XvPortID from one process and use it in another and expect them to be numerically identical < ajax> it's crack but it's an XID < ajax> libXv backending onto this new Render hotness would need to manage that somehow. could be root window properties for all i care, but. < daniels> atoms. < daniels> do they share a space with xids? < daniels> (i should know this.) < ajax> not sure. doesn't really matter that they be legal XIDs, just that the opaque value mean the same thing in all clients. < daniels> okay, atom of (int gpuid, int portid) < ajax> also, as a sloth argument, it's easier to compat it in the server than both: compat on client, rewrite in server < daniels> sure, but i'm talking new driver api + new render api, not when i'm bored next week. :) < daniels> i mean, if your argument is that it's a crap api, sure, but if your argument's that someone needs to do it, then i'll do it because i've written an xv implementation and looked into that code. < ajax> i'm happy to see xv backended on to render, sure. i just don't see a lot of value in moving xv api compat from the server to libXv. < daniels> assuming that we care about the server codebase being both reasonably sized and mostly decrufted, slicing xv off can't be that bad an idea. < daniels> and that bitrotting libraries is something no-one really cares about. < ajax> i suppose i'm being paranoid about xv-on-the-wire mattering for someone < ajax> but, like you said: xv compat in server would _not_ be a large chunk of code < ajax> positing all the stuff mentioned above, it's like... thousand lines or so? most of which is protocol banging? < daniels> sure. < ajax> (also, anyone doing xv on the wire is already a bit barmy, seriously just do mpeg frames, it's less work for both sides) < ajax> i buy the decrufting argument, and --disable-xv for server should still work, but unlike a lot of the other bullshit we've deleted we're starting to approach things that people actually use < daniels> meh, anything other than YUV in requires dealing with the DSP in the X server, and no. < daniels> ajax: yeah. < daniels> ajax: consider me talked over. < ajax> also when i say "on the wire" i mean "between different machines" < ajax> if client and server are same machine, fix the damn player < ajax> if they're not the same machine, you're using more bandwidth than you ought to be < ajax> hopefully in N years everyone will be using gstreamer and we can fix the bottom layer of it at will < ajax> right, so this sounds like a plan then. < daniels> indeed.