<html> <head> <base href="https://bugzilla.gnome.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Wrong (ultra tiny/small) cursor size on HiDPI screen" href="https://bugzilla.gnome.org/show_bug.cgi?id=744932#c131">Comment # 131</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Wrong (ultra tiny/small) cursor size on HiDPI screen" href="https://bugzilla.gnome.org/show_bug.cgi?id=744932">bug 744932</a> from <a href="page.cgi?id=describeuser.html&login=jadahl%40gmail.com" title="Jonas Ådahl <jadahl@gmail.com>"> Jonas Ådahl</a> <pre>(In reply to Owen Taylor from <a href="show_bug.cgi?id=744932#c118">comment #118</a>) > (In reply to Jonas Ådahl from <a href="show_bug.cgi?id=744932#c117">comment #117</a>) > > > The new version of the big-chunk-patch does this now. It could even more > > refactoring, but in summary, drmModeSetCursor2() is now called once per frame > > only, and updating the cursor will queue a redraw which will cause calling of > > the whole stage to be redrawn (well, not really, because there may be no > > damage) with all the drm ioctls with it. > > Have you tested in detail what happens when only moving the HW cursor? Do we > *actually* not paint anything? Do we still page flip? The side effect of doing it this way was that I needed to do a 1x1 pixel damage. So given this, as per IRC discussion, lets wait with doing things like this until we have better control over KMS interaction and can use atomic modesetting. The attached version calls the ioctls in the same way as before, with only the gbm_bo managing changed. Anyhow, the new patches are attached, and I went through the ones that were previously accepted and marked them as such.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> </ul> </body> </html>