| Summary: | Provide a way to align 2 or more windows in a split fullscreen mode with input devices assigned to either window (Feature Request) | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Dimitri Nüscheler <dimitri.nuescheler> |
| Component: | multi-screen | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | REPORTED --- | ||
| Severity: | wishlist | CC: | miranda |
| Priority: | NOR | Keywords: | multiscreen |
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Dimitri Nüscheler
2013-11-09 10:44:23 UTC
Further things: - There should be a way to escape the split-mode without forgetting about the association on return - A way to initiate reassociation - To change the window positions and aspect ratio, especially in case of multiple monitors I don't need to mention that windows become scanout buffers only after full completion of association, because for the decorations you need compositing. As you talk about multi-seat I do not think that KWin is the right component for it. This needs to be a layer below (logind-system-compositor). I don't want to have low-level input control inside KWin. I think the problem is also the terminology. I see the term multiseat as a super domain to what is described here: http://www.freedesktop.org/wiki/Software/systemd/multiseat/ I see it as something that has responsibilities throughout the stack to the finest granularity. If a document has to be edited by multiple users at the same time, then it's the application which has to be able to deal with multiple mouse-pointers. For me this problem also belongs to the multiseat domain, but I think it has nothing to do with logind. I guess some instance (logind?) has to decide which input hardware is assigned to a "session", but is it wrong to have the "session"(kwin?) then further assign these input devices to specific windows. So what is low-level input control? Where do you see a conflict with the design and architecture of kwin if you put a splitscreen mode into kwin? Don't you think that putting it into logind imposes too much of overhead? For every game window you have to start a session, you might even have authentication overhead, wait for it to load a second session? I think it completey kills the added value of the usability-feature I describe. Maybe it's not bad to have the same functionality in logind as well (with some abstraction added using the same shared logic). Another alternative is to have another compositor running inside kwin, but then you can't take existing windows into your session unless wayland-clients learn to jump from compositor to compositor. You add another layer and I really see the splitscreen as a window-managerish problem, because the window manager is the information expert on tiling. Edit: Third paragraph should end with questionmark. I also want to avoid logind in the first place, because I really want to narrow down the "problem domain" to split screen emulation with an innocent focus on games - otherwise you're going to end up in the overgeneralized, overengineered overkill. On Tuesday 12 November 2013 08:24:30 you wrote: > https://bugs.kde.org/show_bug.cgi?id=327356 > > --- Comment #3 from Dimitri Nüscheler <dimitri.nuescheler@sunrise.ch> --- > I think the problem is also the terminology. > I see the term multiseat as a super domain to what is described here: > http://www.freedesktop.org/wiki/Software/systemd/multiseat/ I follow the description exactly used by systemd. Everything I know about multiseat comes directly from Lennart (presentation at DS 2011), so let's please not introduce some other definition. Thank you :-) > I guess some instance (logind?) has to decide which input hardware is > assigned to a "session", but is it wrong to have the "session"(kwin?) then > further assign these input devices to specific windows. KWin currently does not support the concept of multiple seats. I don't see this to change. I do not think that this should have any priority, it clearly is not a scratch-your-own-edge use case for me and I think it's an extreme corner case usecase up to the point where I question whether it's a valid use case at all. During my first work on Wayland support I considered adding support for multiseat as supported by the Wayland protocol, but decided against it. I'm open to see this being added to KWin, but I'm not going to work on it ;-) Considering your usecase of games: I don't think that this is a valid use case for KWin at all. From a performance perspective it might be better to have games just bypass the session compositor completely and run as an own independent session directly on the system compositor. Last but not least we will have to see how games will evolve. Maybe everybody who runs games will be using SteamOS next year - who knows? no idea how troublesome this would be on wayland, but at least assugning different keyboard focuses to different windows might be beyond cornercase, eg. to allow a remote control on a mediaplayer while writing a mail with the realdeal keyboard (couch case ;-) (though i will admit that the current solution to assign the rc special keys, bind them to global shortcuts searching for the next matching client and qdbus/xdotool it works fine for me =) Yeah, MultiSeat is no accurate wording. "human interface device signal and graphics buffer redirection" is better ;-) So with Unix we have an awesome operating system for I/O redirection. Thanks to bash we have a shell for it. And with Wayland we have an awesome display system for "human interface device signal and graphics buffer redirection" Thanks to the resolution of #327356 we have an awesome shell (for part of it). Just kidding - but I really believe that the cleverness of Wayland in design is something I haven't seen since Unix (if I understand it correctly). KWin is my favorite Window Manager today and I'm confident it will be a great Wayland compositor, so of course I wanted to bring this idea here. I understand there are higher priorities, but maybe you can at least give me a suggestion how to start on this? I'm abit of a rookie when it comes to system level programming (sorry to bother you), but I'd love to do this. I don't think it's feasible with KWin scripting, or is it? Should I go and ask logind - are they concerned with similar problems? Should I start with a fresh minimal compositor that runs atop the session compositor? Maybe this is even the right approach. It's some more context switches but for couch gaming the added nano seconds don't matter. Maybe I can adapt/fork KWin code? Reuse effects? > I understand there are higher priorities, but maybe you can at least give me
> a suggestion how to start on this? I'm abit of a rookie when it comes to
> system level programming (sorry to bother you), but I'd love to do this.
as written, I had thought about it when starting the wayland input
redirection. The idea I had back then was to have one Toplevel per seat
element (pointer, keyboard). I decided in the end against it as I thought it
to be too invasive at the moment. In the end it would result in having more
than one "active" window. One active window per seat. That's really a lot of
work I expect and too much to integrate it directly into the Wayland port.
But I like the use case Thomas mentioned. This could be a good enough
solution. If we don't support more than one active application but still allow
to bind an additional seat to send events to another window it might work.
|