<div dir="ltr"><div class="gmail_extra"> <div class="gmail_quote">On Mon, Sep 1, 2014 at 8:33 AM, Derek Foreman <<a href="mailto:derekf@osg.samsung.com" target="_blank">derekf@osg.samsung.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 01/09/14 04:52 AM, Jason Ekstrand wrote: > On Mon, Sep 1, 2014 at 2:37 AM, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> wrote: > >> On Fri, 29 Aug 2014 23:35:37 -0700 >> Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote: >> >>> On Aug 29, 2014 6:25 PM, "Derek Foreman" <<a href="mailto:derekf@osg.samsung.com">derekf@osg.samsung.com</a>> wrote: >>>> >>>> On 29/08/14 06:42 PM, Jason Ekstrand wrote: >>>>> Derek, >>>>> I haven't had a chance to look that hard at or play with this patch >> yet. >>>>> Hopefully I can look at it before too long. One quick question >> though: >>>>> Have you verified that this works with all of the output transforms? >>> I'm >>>>> sorry if this seems premature but a) pixman renderer stuff is hard to >>> get >>>>> right and b) people are constantly breaking the pixman renderer with >>>>> respect to output transforms. So I thought the question was worth >>> asking >>>>> even if I haven't had time to review yet. >>>> >>>> Ouch - I am now guilty of 'b' >>> >>> That's OK. I, for one, can never get pixman changes right on the first >>> try. That's why I asked. ;-) >> >> We'd really need to hook pixman renderer into the headless backend, let >> the test extension do screenshots, and write some tests to test all the >> output transforms... it's a big task, but would be hugely useful and >> allow to write more tests that can check real on-screen results. I've >> been dreaming about that for a while. </div></div>FWIW that's on my TODO list right now, just haven't really started it yet. Perhaps I should give it a higher priority. <div><div class="h5"> >>>> Transforms do indeed break - the zoom translation is being applied in >>>> the wrong direction for some, and the clip region needs to be rotated >>>> for others. >>>> >>>>> FWIW, I have a series on my github that accomplishes the same thing >> only >>>>> with substantially deeper changes to Weston: >>>>> >>>>> <a href="https://github.com/jekstrand/weston/commits/wip/transforms" target="_blank">https://github.com/jekstrand/weston/commits/wip/transforms</a> >>>> >>>> Interesting... >>>> >>>> I think I can re-work my patch to handle rotations/flips pretty easily, >>>> though the code will bulk up a little. >>>> >>>> Is that worth the time, or would you prefer to move forward with yours? >>> >>> I think mine is ultimately a better way forward. The big advantage is >> that >>> it provides a surface to/from buffer coordinates matrix and gets rid of >> all >>> of the transform logic from the pixman renderer. Part of the reason the >>> pixman renderer is always breaking is that it's a separate >> render/transform >>> path from the go renderer and the two can get out of sync. Also, pixman >>> does things more-or-less backwards from GL so it's hard to get right. >>> >>> My patches shouldn't need much of a rebase. The reason I never pushed >> them >>> was that fixing zoom in the pixman renderer was never the end objective >> and >>> I never considered the series really finished. However, if else want >>> zoom+pixman, they are probably good to go. >> >> Oh yeah, finishing Jason's transformations revolution would be very >> good. I should probably take a quick look if someone wants to pick it >> up, since I don't recall if/what we agreed on the basic principles like >> weston_matrix vs. pixman matrix etc. >> >> Pixman is not the only rendering path that has to manually unravel and >> redo everything, rpi-renderer is the other one. Currently Weston's core >> has been written to support only the GL-renderer with its funny >> normalized GL coordinate spaces, which means the common transformation >> code (like output zoom handling) is practically useless for any other >> renderer that might (*gasp*) want to deal with pixel coordinates. >> > > You should look at my patches. They fix some of that. :-) Don't quite fix > the rpi stuff though. > > I got a fair ways with those patches but blocked on a few things and then > didn't have time to finish. Here's roughly what needs to be done: > > 1) Add region transform code that transforms a region based on a matrix. > 2) Use said region transform code to do region transforms instead of the > current ints+enum version > 3) Write a function to detect if a matrix is a combination of integer > translation, integer scale, 90-degree rotation, and possible flip. If it > is, return the data needed to reconstruct it as such. > 4) Use said function for a bunch of things; > a) Inside of the GL renderer to determine whether GL_LINEAR or > GL_NEAREST should be used > b) Inside of the DRM backend to determine if something can go in a > plane > c) Maybe in the RPI renderer for some things? > > That's a rough sketch for what I had intended. Then there was stuff about > damage coordinates but that's blocking on getting at least 2) if not 3). </div></div>I'm quite willing to pick that up if you don't mind the occasional silly question on IRC... </blockquote><div> </div><div>Cool! I would love to see that go forward, I just don't have the time at the moment to work on it. Silly IRC questions welcome! Just direct them at "jekstrand" </div><div>--Jason </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=""> > --Jason > > >> The current code also makes using hardware overlays in e.g. DRM-backend >> more of a hassle than it needs to, because there too you would like to >> have the end-to-end pixels-to-pixels transformation to program the >> overlays. >> >> So roughly the big idea would be that Weston core provides coordinates >> and transformations end-to-end from buffer to output in raw pixels, and >> if the renderer has something strange like GL, it should do the >> adaptation in its own code. >> >> I don't recall complaints about zoom on pixman renderer, but maybe >> that's because I've known it is broken. </div>I found it in the bugzilla (80258) - though the user thought it was a problem with transparency and misreported it. The problem isn't really a lack of zoom, more the incredibly anti-social way in which weston reacts to the lack of zoom. Once you enable zoom it starts dumping the same "zoom not supported" warning into the log file every time a frame should be rendered, and never actually rendering. It gives the impression that weston is crashed, when it's actually just not bothering to do anything visible. I guess I'll send another patch that makes it log the warning once, and just continue to draw without the zoom. I suppose maybe we don't want to paper over this one, but to me the failure mode seems a little heavy handed and it's pretty easy to accidentally enable zoom when you intend to adjust window transparency. <div class=""> >> IMHO, working towards that testing thing or pushing Jason coordinate >> revolution forward would be time better used than patching pixman >> renderer case by case. </div>Nod - fixing my patch to provide output rotations would continue the proliferation of ugly switch statements in the pixman renderer. <div class="im HOEnZb"> >> >> Thanks, >> pq >> >>>>> On Aug 29, 2014 7:56 AM, "Derek Foreman" <<a href="mailto:derekf@osg.samsung.com">derekf@osg.samsung.com</a>> >> wrote: >>>>> >>>>>> Currently if you try to zoom with mod+scrollwheel the pixman >>>>>> backend will stop rendering anything at all and will continuously >>>>>> log "pixman renderer does not support zoom", giving the impression >>>>>> that the server is hung. >>>>>> >>>>>> Instead, this patch adds the missing zoom functionality. >>>>>> >>>>>> This should close BUG 80258 >>>>>> --- >>>>>> src/pixman-renderer.c | 65 >>>>>> ++++++++++++++++++++++++++++++++++++++++++++++----- >>>>>> 1 file changed, 59 insertions(+), 6 deletions(-) >> > > > </div><div class="HOEnZb"><div class="h5">> _______________________________________________ > wayland-devel mailing list > <a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a> > <a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a> > </div></div></blockquote></div> </div></div>