<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Nov 22, 2012 at 10:02 PM, Peter Hutterer <span dir="ltr"><<a href="mailto:peter.hutterer@who-t.net" target="_blank">peter.hutterer@who-t.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">On Tue, Nov 20, 2012 at 02:50:40PM -0500, Jasper St. Pierre wrote:<br>
><br>
> This is a heavy modification of RAOF's patch set that's used in Ubuntu<br>
> for Unity and was was once proposed here. This implements the server side:<br>
> xiproto [1] and libXi [2] patches are boring and bland, and read as you<br>
> pretty much expect. If there isn't too much turbulence with this current<br>
> patch set, I'll go and attach them here for a more formal review of<br>
> those. I'd like to get this in for 1.14, and I understand this is sort of<br>
> a tight schedule.<br>
<br>
</div>I don't want to make any promises here, but I suspect this is more likely to<br>
land for 1.15. Over the last couple of releases we've merged features that<br>
were decidedly incomplete (touch, smooth scrolling, as two examples) and<br>
fixing them up under time pressure has not been useful. So this one I want<br>
to actually get done and tested before we merge it.<br>
<br>
1.14 may still be possible if it turns out to be easier and we have enough<br>
test cases to assume that it's not broken out of the box (like touch pointer<br>
emulation for example). but if you set your mind to 1.15 now, you get spared<br>
the disappointment later :)<br><div class="im"></div></blockquote><div><br>Noted, but GNOME would like to have this for 3.6, so 1.14 would be extremely wonderful. I'll try the best I can to work on appropriate test cases. I'm having fun writing them -- good work on xorg-integration-tests and xorg-gtest!<br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">
> There are a few limitations and issues with the current patch set, but<br>
> hopefully these can live as-is for now, fixing up the implementation<br>
> later.<br>
><br>
> Limitations:<br>
><br>
> 1. Barriers on screen edges will not get events, due to<br>
> unintended interactions between RANDR and barriers. Multiple<br>
> solutions have been discussed on #xorg-devel, but none of them<br>
> are easy and convenient to fix. This is an extension of bug<br>
> #48008 [3] in some ways.<br>
<br>
</div>this is something that we should consider fixing, as it makes the corner<br>
hotspot use-case easier to clients.<br><div class="im"></div><br></blockquote><div><br>It's something that's extremely difficult to fix. One of the recommended solutions was to implement monitor edges in terms of barriers, but this is a big change in semantics. The ASCII art on the bug spells it well -- right now, as far as I'm aware, the ability to cut corners like that is a feature.<br>
<br>The hacky-but-might-just-work solution is to recognize barriers that are touching monitor edges and extend them automatically downwards to the bottom of the screen for clients. I've been wondering myself if defining a new barriers API in terms of monitor corners and edges might be worth it.<br>
<br>If you have any other ideas, I'd be more than happy to try them out.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">
> 2. Overlapping barriers will not work: only one will receive<br>
> events. This is an extreme edge case, considering that<br>
> window managers are supposed to be the intended user of<br>
> barriers, and that they control their own destiny.<br>
<br>
</div>this should be explicitly clarified in the protocol. something along these<br>
lines:<br>
"pointer motion is blocked at the closest barrier blocking in the given<br>
direction. If two or more barriers block on the same coordinates, the first<br>
barrier is considered blocking.<br>
Barrier events are only sent to the one blocking barrier (if applicable) for<br>
the current direction"<br>
<br>
Bonus points for making it really predictable, e.g. oldest barrier wins<br>
(which, given that we have a list of barriers, should be easy enough)<br>
<br>
which brings the next point - should barriers be assigned to windows, where<br>
useful?<br><div class="im"></div></blockquote><div><br>I'm not sure about this. This seems to be a quality-of-implementation issue, and I can't ever imagine it coming up in the real world. While never likely, I'd like for someone to be able to add this ability in the future if they desire.<br>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">
> 3. Releasing a barrier will lose pointer acceleration across<br>
> the barrier. Unity's current use case includes releasing<br>
> a barrier when the pointer is at high velocity, so it may<br>
> be worth re-introducing a "velocity barrier", which is only<br>
> solid at speeds less than some threshold.<br>
<br>
</div>this is honestly something that I'd like to have tested reasonably well in<br>
real-world situations before merging. it's all nice if we can push through,<br>
but if the end result is confusing pointer motion, we need to find a better<br>
solution.<br>
<div class="im"><br>
> 4. The interaction with grabs hasn't been decided yet; as with<br>
> existing barriers, a pointer grab will still allow barriers<br>
> to constrain the cursor. Currently, an event is sent to the<br>
> appropriate client when a barrier is hit, always, even when<br>
> a different client has a grab on the pointer. Semantics can<br>
> and probably should be tweaked here.<br>
<br>
</div>this is a can of worms that we really need to sort out before we merge<br>
anything because I suspect this can make or break the whole approach.<br>
<br>
- if you're sending events while a grab is active, can the non-grabbing<br>
client release the pointer from the barrier?<br>
- if not, what's the point of sending the event in the first place? is there<br>
one? (honestly not sure here, we don't send enter/leave events either<br>
during grabs iirc) </blockquote><div><br>GNOME's use case is wanting a "pressure barrier" -- if you press hard enough against a barrier, things happen. We don't want to release barriers, but simply use the dx/dy values to build up pressure, and Do A Thing when the pressure passes some threshold. I think that this should happen during drag-and-drop as well. I think of pointer barriers right now as ways to extend Fitts's Law in cases where the desktop environment knows more about how it is laid out than Xorg, so I think that barriers being dropped during pointer grabs makes as much sense as not doing RANDR clamping during pointer grabs.<br>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- if you're sending events during grabs but the client cannot release, how<br>
will the client know that the device is grabbed? destroying the barrier<br>
may be a use-case in response to hitting it but the client needs to know<br>
if a grab is active here.<br>
- if you're _not_ sending events while a grab is active, the UI experience<br>
is inconsistent. a grab is always activated on button press, so if you're<br>
planning to drag and drop something but you hit a barrier on the way -<br>
what's the behaviour there?<br>
<br>
the last point also feeds in with point 1, where we could and should use<br>
barriers for corner hotspot.<br>
<br>
one more thing I found when testing the first patch you sent (the wobbly<br>
cursor one): how likely is it that a user sticks to the barrier until a<br>
release request arrives? I find that even when I try really hard to move<br>
right only along the barrier, I tend to get the odd x-1 event. which would<br>
generate a new event_id, thus trigger a new block/release cycle.<br>
do you have any data on that yet?<br></blockquote><div><br>I noticed it in testing, but wasn't sure how widespread it was, or whether it was local to my touchpad / driver / configuration / distribution / etc.<br><br>
When giving these patches to other people to try out, they've encountered the same issues.<br><br>I still don't know if it's a Synaptics bug or not, but for now, I've added a 2px "hit box" on either side of the barrier that won't reset the event that gives a bit of wiggle room for this bit of bouncing pointer.<br>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Cheers,<br>
Peter<br>
</blockquote></div><br>-- <br> Jasper<br><br>
</div>