On Thu, 02 Oct 2014 17:21:04 -0500 Derek Foreman <der...@osg.samsung.com> wrote:
> On 02/10/14 02:37 PM, Jason Ekstrand wrote: > > > > On Oct 2, 2014 12:37 AM, "Pekka Paalanen" <ppaala...@gmail.com > > <mailto:ppaala...@gmail.com>> wrote: > >> > >> On Wed, 1 Oct 2014 18:09:32 -0700 > >> Jason Ekstrand <ja...@jlekstrand.net <mailto:ja...@jlekstrand.net>> wrote: > >> (Total transformation is between buffer pixel coords and output/scanout > >> pixel coords, i.e. buffer-to-output.) > > btw, what exactly is the buffer-to-output transform? I think in the > pixman renderer that's already calculated in a convenient location (in > "matrix" in repaint_region() Yes, like Jason already replied. It is from pixel coordinates in buffer to pixel coordinates in output. Unnormalized. Raw in the sense that you can theoretically use them directly with pointer arithmetic to address pixels. > For gl-renderer, I suspect I need to build it myself in draw_view(): > weston_matrix_init(&foo); > weston_matrix_multiply(&foo, &ev->surface->buffer_to_surface_matrix); > if (ev->transform.enabled) > weston_matrix_multiply(&foo, &ev->transform.matrix) > weston_matrix_multiply(&foo, &output->matrix); > > Is that right? Do I have the order backwards? > > I'd like to test just that one matrix and no additional if > (ev->tranform.enabled) etc to decide on whether to use linear or nearest... I can't bother to think far enough to say anything about the order right now, but all this is what Weston core should be computing when you're done (maybe a helper function called from renderers). So the generic computation would be moved from pixman to core, and then only pixman specifics are left in pixman renderer. For the gl-renderer this means much bigger changes: the renderer receives a pixels-to-pixels transformation matrix which is the canonical form, and then it needs to adapt it to the normalized GL coordinate system. You have various options on how to implement that: do you compute all coordinates on CPU and feed both vertex and texture coords to GL, or do you feed a matrix and either vertex or texture coords to GL? I can't say off-hand what is best, but I think you'll know when writing the code. (Maybe you already did? Sorry, I still haven't looked at the patches.) > > I'm sorry I mistyped but I meant the transform to be an output > > parameter. That way you know of the matrix is a 90-degree rotation or > > flip. Not sure if this is needed but for figuring out GL_LINEAR vs > > GL_NEAREST we don't want to fail if there is a 90-degree rotation. > >> > >> > (do we use "bool" in weston? Maybe just return int). We may need > > I'm kind of interested in the answer to the question "do we use bool in > weston?" - It's used in some places and not others - do we care? :) Hmm... it's used in so many optional places, that I guess we can just use it also in the core. Just make sure the semantics are logical. A test function of the form foo_is_bar() or is_foo() can return bool and it makes sense, but an imperative function usually returns success/failure. If success/failure is returned as int, we use -1 for failure and 0 for success, which is the opposite of bool. Except the places where we use int return with 1=success and 0=fail... After a pause, I always need to think three times what the return value for weston_output_repaint() means. :-P All I'm saying is that an imperative function (do_something()) returning bool vs. returning int can be easily confused... Eh, cleanups to bring consistency would be appreciated. And first determining what the common convention actually is. ;-) > > both x > >> > and y scales and it may be useful to get those as floats. I'm not > > sure on > >> > that. Pekka, what would the RPi backend use? > >> > >> The rpi-renderer uses pretty much the same as what DRM planes/overlays > >> offer wrt. coordinates, IIRC: integer position and size on the output, > >> and 16.16 fixed point position and size on input (buffer). > >> > >> Whether scaling factor is integer or not is irrelevant there. I do not > >> recall there being an option for sampling (nearest/linear/...) in > >> either DispmanX nor DRM. > > I think rpi has horizontal and vertical flip capabilities as well? > > I don't think that's exposed by drmModeSetPlane. You clip by setting the source rectangle to smaller than the buffer. extern int drmModeSetPlane(int fd, uint32_t plane_id, uint32_t crtc_id, uint32_t fb_id, uint32_t flags, uint32_t crtc_x, uint32_t crtc_y, uint32_t crtc_w, uint32_t crtc_h, uint32_t src_x, uint32_t src_y, uint32_t src_w, uint32_t src_h); Thanks, pq _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
