On Thursday 25 October 2012 13:39:23 you wrote: > > In this specific case, we sort of do have input redirection - it's just > > a mouse capture to the given window. And this would solve a lot of other > > problems. Requiring a compositor in the mix might kill this for games > > though - Ryan, thoughts? > > This WM hint could certainly be used as a clue that the entire screen is > occupied and thus doesn't need compositing. Is that what you were asking? no, I think that was not meant. Instead of changing the resolution the compositor could upscale the window. This would of course not work if unredirection is used. > > > It's possible that the right answer is to basically implement the > > proposed protocol as an x extension instead of a wm extension. > > My thought is that the Window Manager would want to handle some > specifics (to wit: it would want to manage some windows), but the > absolute heart of the problem is that some central authority needs to be > in charge of resolution changes, not every app, and an X extension could > solve that too. I hope we could agree that nobody wants to change the resolution, but that faking the "right" resolution for the game window should be enough. In the Wayland world that is the compositor (easy, controls both screen and input) in the X world it could be either the compositor (downside no "direct" input in compositor, unredirection does not work) or the X-Server. If it's in the X- Server it would just work with all systems and would be without changing all other windows. > > My instinct is that it's the wrong layer to work in, but it can probably > also solve the worst parts of the problem. Let's see if we can agree on > a Window Manager solution first, though. Let's try to find the best solution. For me that is not changing the resolution while supporting what the games need. If that can be done in X it's better than trying to change all window managers. > > --ryan.
Attachment:
signature.asc
Description: This is a digitally signed message part.