On Sun, 09 Mar 2025 21:03:43 +0100 Django Reinhard <django...@gmx.de> said:
> Am Sonntag, 9. März 2025, 13:44:05 CET schrieb Carsten Haitzler: > > is your problem that kde splits the "desktop" screen by screen and each > > screen may have its own panels or when you maximize a window or go > > full-screen it maximizes/fullscreens on that screen as opposed to spanning > > all your monitors? > > well - for me: one desktop means one background image of whole size and not > one background image for each monitor. > And yes - it means too, if I maximize a window, it spans all monitors as > opposed to span one single monitor only. > > Xinerama worked that way - one desktop which spans multiple monitors. > KDE does not work that way. With kde you have 3 desktops, that fit together > and you'll be able to size a window manually that spans all monitors. But it > is not possible to maximize a window for all monitors. well.. xinerama didn't work this way... xinerama also exposed which regions map to which monitor like xrandr does. i know. i added the support for it decades ago when it was still young and new and fresh... :) it may have been kde chose not to add such support or to treat it like zxrandr output info - but. i didn't use kde. but moving from xinerama -> xrandr for me was a non-event as it already worked the same way. the method via which i could get the data was a different extension and xrandr allowed on the fly runtime changes, unlike xinerama. what xinerama REALLY was, was putting 2 xserver implementations running inside the xorg server driving 2 entirely separate gpu cards that duplicated everything they did. every window created was created 2 times. every pixmap was created 2 times (once on each card). every draw was done twice. the output to the root window as clipped to a region per monitor. that's what xinerama was. :) it was pretty grossly inefficient but it was a neat and working hack. this was bakc in the days where to do multiple monitors you literally bought 2 gpu's and stuck them in 2 pci slots. for a while multiple outputs on the same gfx card then mimicked xinerama information that as exposed to clients via the xinerama extension but didn't run 2 xservers as above on 2 cards. this is when xrandr began its replacement or xinerama. xinerama now is pretty much dead and buried. so it's not a xinerama issue. it's a "kde issue". i suggest you have a chat with kde devs about what you want. > Background image handling is a problem. In the beginning I thought, I might > split the background image in 3 parts, so that each monitor shows a third of > the whole image - but I like to use diashow for backgrounds, and it's not > possible to sync background changes for all monitors (or at least I wasn't > able to solve it). it's pretty easy wrote a script that uses imagemagick to take any image, crop it into 3 images then use scripting to ask your desktop to set each image to each screen. you could ask disahow devs to add this as a core feature built-in. or you could do that work yourself and send patches. :) same for the above kde stuff. one of the reasons no one really wants to do this anymore is the problem of different monitors with differing rotations and resolutions - in which case a screen is no longer a rectangle - it may be a series of differently sized rectangles (e.g. 2 screens same dpi, one 1280x720, another 1920x1080 - a panel spanning the bottom of the screen gets cut off on one of your screens - a maximized window across all screens will have part of it disappear on one of those screens...). it ONLY really works if all screens have the same dimensions (at least e.g. in height if you place screens left to right - but the problem continues with one monitor above another etc.). it's kind of a nasty problem space no one really wants to solve as the number of users who demand this is so vanishingly small that it doesn't justify the complexity and code. :) but... i encourage you to talk to your neighbourhood kde devs or try come up with patches that make this work in kde with xrandr and send those patches to them for review. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com
