I like the second-class seat proposal. got the roughly same idea called it a focus inherit seat.
It's kind of a child seat that is, for some reason, not capable to change it's own focus, instead it follows the mother seat focus. Nice thing is, the seat id = player id, making the player id redundant. Another nice thing is, the application can still recognize the seats, making implementing sub compositor easier. Most common scenario would be: A: joypad 1 on mother seat with keyboard and pointer B: joypad 2 on child seat Let's say: - user plugs another keyboard and pointer, udev assigns it to B: - weston promotes B: to mother seat The situation is as follows: A: joypad 1 on mother seat with keyboard and pointer B: joypad 2 on mother seat with keyboard and pointer The seats are now independent and can control the UI, user 2 can now quit the focus on the fly. But the question is.. Is this the expected? Let's say there is a full screen application and the user 2 presses alt+tab, now we have a surface stacking/ordering race. But let's say it got assigned to A: A: joypad 1 on mother seat with 2x keyboard and pointer B: joypad2 on child seat So everything is ok, therefore the device-seat assignment policy would be used this way to control the expected behavior. _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel