Hi, > This still suffers from your priority-starvation-bug. If a simple > ping/pong protocol barrier doesn't solve the issue, why would the > timer? You'd have to put the timer on lowest priority to make that > work, but then again you can do the same for wl_display_sync. Yup, indeed, you're right. I guess we just need to fix the compositor here.
> Btw., if your compositor stalls for a bit more, you end up with an > evdev-queue overrun and have more trouble than you can solve. Is it > really worth solving that single race, while there're still several > known other issues that happen on stalling compositors? My concern is that we don't end up with spurious repeat events. I don't want a relatively benign compositor stall (which is a bug and should be fixed!) leading to 15 mails getting deleted instead of 1 mail getting deleted when the user hits delete once. > Why not rather put keyboard handling on high-priority? > It is low-throughput, anyway. fair. --Ray _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
