Re: [RFC] wl_surface scale and crop protocol extension
On Fri, 03 May 2013 12:11:17 -0700 Bill Spitzak spit...@gmail.com wrote: Pekka Paalanen wrote: What chip do you have in mind, that can do arbitrary matrix-based transforms during an overlay scanout? That just means the surface cannot use the overlay, or the compositor has to use an intermediate image. There are lots of other reasons the surface does not use the overlay, such as not being the top one. Ok, so there is no use for what you suggested. Very good. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Documentation cross-reference (Re: [RFC] wl_surface scale and crop protocol extension)
On Fri, 3 May 2013 19:16:41 +0100 Daniel Stone dan...@fooishbar.org wrote: On 3 May 2013 18:50, Bill Spitzak spit...@gmail.com wrote: Currently one of the things you can do to a wl_surface is that you can find the wl_shell object and ask it to create a wl_shell_surface object given a wl_surface id, and then you can do things to this wl_shell_surface object. However this is not listed under wl_surface, instead it is listed under two other sections with no links to them (there are backward links but that is pretty useless): wl_shell and wl_shell_surface. I think this is extremely confusing and was probably one of the biggest obstacles I had trying to figure wayland out. What I would like to see is that under wl_surface you see a section that says something like wl_scaler:. Listed under that are the methods that are currently listed under wl_surface_scaler. The title wl_scaler: implies all this information: the actual calling convention is to find the global wl_scaler object, call a method called get_scaler_surface with the wl_surface id, and that returns a new object called a wl_scaler_surface, and you call the listed methods on *this* object. The documentation is now where a user can find it, and a lot of boilerplate is elided. One thing that would help a lot is for there to be a standard as to whether a wl_foo global object, when asked to create an object for a wl_bar object, that the object is called wl_foo_bar and not wl_bar_foo. Currently the wl_shell and wl_scaler disagree about this. Since wl_shell_surface is in much more than wl_surface_scaler use I recommend standardizing on putting the global object's type first. OK, so it pretty much looks like just cosmetic/documentation changes - none of which I'm against at all. Obviously we can't break existing protocol though (such as renaming wl_shell_surface to wl_surface_shell), but we can improve the documentation. I'm sure patches for that would be gratefully accepted. How about automatically generating a cross-reference list for each object class, which would contain every request and event that has this object class as an argument (and make those links to the corresponding doc)? This would be for the html/pdf docs. Now, who would implement that... Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Input and games.
On Fri, 3 May 2013 17:42:20 +0100 Daniel Stone dan...@fooishbar.org wrote: Hi, On 3 May 2013 08:17, Pekka Paalanen ppaala...@gmail.com wrote: On Thu, 2 May 2013 19:28:41 +0100 Daniel Stone dan...@fooishbar.org wrote: There's one crucial difference though, and one that's going to come up when we address graphics tablets / digitisers too. wl_pointer works as a single interface because no matter how many mice are present, you can aggregate them together and come up with a sensible result: they all move the sprite to one location. wl_touch fudges around this by essentially asserting that not only will you generally only have one direct touchscreen, but it provides for multiple touches, so you can pretend one touch each on multiple screens, are multiple touches on a single screen. Right. Could we just say that each such non-aggregatable device must be put into a wl_seat that does not already have such a device? Or make that an implementors guideline rather than a hard requirement in the protocol spec. *shrug*, it really depends. If we're going to say that gamepads are associated with focus, then they have to go in a _specific_ wl_seat: the focus is per-seat, so if we're saying that clicking on a window with your mouse to focus it (or Alt-Tabbing to it) also redirects gamepad events there, then the gamepad needs to be part of _that_ seat which changed the focus. Remember that we can have multiple focii per the protocol (though the UI for that gets very interesting very quickly). If they're unaffected by the focus - which they would be if they're just going into random new wl_seats - then they shouldn't be in wl_seat just because it's the container we have for input devices right now, they should have their own interfaces. Which really means wl_gamepad_manager which, when bound to, advertises new_id wl_gamepads. tl;dr: wl_seat has a very specific meaning of a set of devices with one focus, please don't abuse it. I'm not too clear on what it is. In a wl_seat, we have one kbd focus, and one pointer focus. These two are unrelated, except sometimes some pointer action may change the kbd focus. Most of the time, they have no relation. I was thinking of adding a third one: the gamepad focus. It could be independent from kbd and pointer foci, or maybe it is assigned with the kbd focus. Or maybe the gamepad focus is assigned to the surface having any wl_seat's the kbd focus, whose client has bound to the gamepad. In any case, we have the fundamental problem: which client gets the gamepad events at a point in time? There can be several clients bound to any gamepad, and the target (focus) must be switchable intuitively. Is it wrong to think a wl_seat as a user--a player, that may have a gamepad? It's just too tempting for me to think that each player corresponds to a particular wl_seat. The gamepad interaction doesn't have this luxury, and neither do tablets. I don't think splitting them out to separate seats is the right idea though: what if (incoming stupid hypothetical alert) you had four people on a single system, each with their own keyboards and gamepads. Kind of like consoles are today, really. Ideally, you'd want an association between the keyboards and gamepads, which would be impossible if every gamepad had one separate wl_seat whose sole job was to nest it. So... what's wrong in putting each keyboard into the wl_seat where it belongs, along with the gamepad? In that case, yes, we would have wl_seats with one wl_keyboard and multiple wl_gamepads. I think it'd be better to, instead of wl_seat::get_gamepad returning a single new_id wl_gamepad, as wl_pointer/etc do it today, have wl_seat::get_gamepads, which would send one wl_seat::gamepad event with a new_id wl_gamepad, for every gamepad which was there or subsequently added. That way we keep the seat association, but can still deal with every gamepad individually. It would be left for the client to decide which gamepad it wants from which wl_seat, right? Do we want to force all clients to choose every non-aggregatable device this way? No idea. :) Essentially, that would mean that wl_seat are just for the traditional keyboard mouse (and touchscreen so far) association, and then everything else would be left for each client to assign to different wl_seats on their own. This seems strange. Why do we need a wl_seat then, why not do the same with keyboards and mice? Oh right, focus. You want to be able to control keyboard focus with a pointer. Why is a gamepad focus different? Would all gamepads follow the keyboard focus? If there are several wl_seats with kbd ptr, which keyboard focus do they follow? What if the same gamepad is left active in more than one wl_seat? What if there is no keyboard or pointer, e.g. you had only a touchscreen and two gamepads (say, IVI)? And then replace every gamepad with
Re: Input and games.
On Sun, May 5, 2013 at 12:55 PM, Pekka Paalanen ppaala...@gmail.com wrote: In a wl_seat, we have one kbd focus, and one pointer focus. These two are unrelated, except sometimes some pointer action may change the kbd focus. Most of the time, they have no relation. As a total aside, OSX has this and it drives me nuts. Scrollwheel focus follows the pointer, keyboard focus doesn't. In practise what that means is that whenever I'm on OSX I wind up closing the wrong thing. Example: - running an irc client and firefox - colleague sends an url, I click on it - firefox brings up the url, I mouse over to it and scroll through with the scroll wheel - I'm done with the link, clover-w to close the tab, and it closes my IRC session instead, because keyboard focus never left the irc window I've had to use OSX for a couple of years now because of some iOS projects we've been working on, and this still bites me at least once a day. It's *completely* counterintuitive GUI behaviour. I was thinking of adding a third one: the gamepad focus. It could be independent from kbd and pointer foci, or maybe it is assigned with the kbd focus. Or maybe the gamepad focus is assigned to the surface having any wl_seat's the kbd focus, whose client has bound to the gamepad. In any case, we have the fundamental problem: which client gets the gamepad events at a point in time? There can be several clients bound to any gamepad, and the target (focus) must be switchable intuitively. Is it wrong to think a wl_seat as a user--a player, that may have a gamepad? It's just too tempting for me to think that each player corresponds to a particular wl_seat. I don't think there's any problem in principle with the gamepad events being delivered to the same client that has keyboard focus. The only annoying thing is if (in a multiplayer game) someone can screw you by sending you a well-timed IM that pops up a window and steals focus, but honestly I think that's more an argument against focus stealing than it is for not attaching gamepad focus to keyboard focus. I don't see any reason why you couldn't have two (or N, for some reasonable N) games running at the same time, using the same gamepad, and only the program with focus sees gamepad events. There are some tricky cases, if the game wants to have multiple windows with no containing root window, for example, but maybe that's one of those well, don't do that, then cases. Having given it some thought, I'd be inclined to be cautious about how much you consider the gamepad-with-builtin-keyboard case. They really made those things to make MMOs viable on game consoles. As far as I know, not a lot of people have them, and the main argument for them is on consoles which don't have native keyboards. On a PC, the kinds of games that need keyboards are the kinds of games you tend to want access to the mouse. That's not to say that nobody will ever use a gamepad keyboard in a game on Linux, but I'd argue it's on thin enough ground that I wouldn't let it drive the design considerations. Todd. -- Todd Showalter, President, Electron Jump Games, Inc. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
