Feature Request: Choose display output device

[mxwmnn]

Hey,

I wanted to ask if it's possible to add an argument that defines which display it will show the Mirroring and/or the Cover with Audio.

In my case the device is connected to 3 HDMI Displays, but it always opens the gstreamer stream on the Main Display which is configured in the settings. But i want it on another display always. How can i force it?

Thanks

[fduncanh]

The covert art is written to a file with the -ca option. You then use a releading image view (e.g. "feh" on linux X86 desktops) to view it. Presumably you can specify which display to display it on.

Gstreamer picks the display for the mirror window. I see the X11-based videosinks (ximagesink, xvimagesink) have a an option display=<x> where <x> is a "gchararray". I don't know what the expected values for <x> would be, and dont have a second display to experiment with.

It seems it depends on the videosink used. you can add options using quotes, for example

uxplay -vs "xvimagesink display=<?>"

except you need to find what <?> should be

https://gstreamer.freedesktop.org/documentation/xvimagesink/index.html?gi-language=c

maybe google for help (or use chatGPT for clues!)

This person looked into it https://stackoverflow.com/questions/71219343/specify-a-display-for-a-sink-in-gstreamer

If you can work out what to do, its fairly easy to add some -display x option to UxPlay to make it easy for the general user.

https://datacadamia.com/ssh/x11/display

[fduncanh]

This doesn't seem too promising:

https://gstreamer-devel.narkive.com/AokxUqN3/problem-setting-display-parameter-in-xvimagesink

[Post by Subodh](https://gstreamer-devel.narkive.com/AokxUqN3/problem-setting-display-parameter-in-xvimagesink#post1)
Hi,
I am trying to use the display parameter to choose the monitor I want to
output my video on.
Following is my xrandr configuration
[...]
The display property on xvimagesink configures the X11 display that is
used, e.g. ":0". If you have a multi-monitor configuration you will
still only have a single X11 display.

That answer is from an expert (S. Droge) . It seems that "display=" means something else.?

maybe look into xdotool to move windows between different monitors?
https://manpages.ubuntu.com/manpages/trusty/man1/xdotool.1.html

[mxwmnn]

Thanks for the suggestions, i'm already searching a while. Using waylandsink btw.

[fduncanh]

https://gstreamer.freedesktop.org/documentation/waylandsink/index.html?gi-language=c

waylandsink also has a "display=" option.

display

“display” [gchararray]

Wayland display name to connect to, if not supplied via the GstContext

Flags : Read / Write

Default value : NULL

EDIT: found this

https://stackoverflow.com/questions/71219343/specify-a-display-for-a-sink-in-gstreamer

[fduncanh]

more info

https://www.baeldung.com/linux/primary-monitor-x-wayland

[fduncanh]

https://unix.stackexchange.com/questions/331488/is-it-possible-for-a-x-server-to-have-multiple-displays

I guess the question is: how may instances of the X server are you using? Maybe you mean "multiple screens" on a single X11 "display"? (Except Wayland is not X11....)

[mxwmnn]

https://unix.stackexchange.com/questions/331488/is-it-possible-for-a-x-server-to-have-multiple-displays

I guess the question is: how may instances of the X server are you using? Maybe you mean "multiple screens" on a single X11 "display"?

ps aux | grep X root 459 0.0 0.0 0 0 ? S 19:48 0:00 [irq/134-PIXA3854:00] root 2645 0.0 0.4 1375264 77568 tty2 Ssl+ 19:48 0:00 /usr/libexec/Xorg -nolisten tcp -background none -seat seat0 vt2 -auth /run/sddm/xauthzqJEhZ -noreset -displayfd 15 frmwrk+ 3369 0.0 0.4 779720 73852 ? Sl 19:49 0:00 /usr/bin/Xwayland :1 -auth /run/user/1000/xauthJzzWPn -listen 53 -listen 54 -displayfd 45 -rootless -wm 48 frmwrk+ 347313 0.0 0.0 222044 2560 pts/1 S+ 21:38 0:00 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn --exclude-dir=.idea --exclude-dir=.tox X

[mxwmnn]

I have only 1 screen what xrandr outputs. Like they said from your infos Screen 0: minimum 16 x 16, current 6150 x 2854, maximum 32767 x 32767 XWAYLAND1 connected 2400x1350+0+0 (normal left inverted right x axis y axis) 0mm x 0mm XWAYLAND2 connected primary 2400x1350+2400+0 (normal left inverted right x axis y axis) 530mm x 300mm XWAYLAND3 connected 1350x2400+4800+0 right (normal left inverted right x axis y axis) 300mm x 530mm XWAYLAND4 connected 2256x1504+2543+1350 (normal left inverted right x axis y axis) 280mm x 190mm

[fduncanh]

https://wayland.freedesktop.org/xserver.html

bottom line is, if a waylandsink option (e.g. display=(something)) can handle the issue, it can easily be added as a uxplay option.

https://gstreamer.freedesktop.org/documentation/waylandsink/index.html?gi-language=c

[mxwmnn]

Okay okay tested some things.

If i change primary display with https://www.baeldung.com/linux/primary-monitor-x-wayland#1-changing-the-primary-monitor-in-kde-plasma. it's just like in the settins from kde fedora so the taskbar moves to this one, but the output from uxplay NOT.

If i move the konsole app to the external monitor i want to and execute uxplay without parameters, it outputs on this display where the konsole is active and started. LOL strange but i can work with that maybe

[fduncanh]

So the mirror window will show on the same screen as the terminal in which uxplay is running?

I am confused between "display" and "screen" since they do not appear to be synonymous?

Right now the way gstreamer is called on UxPlay does not provide a "context", so gstreamer just does its own thing. To do something more sophisticated, one needs to prepare a "context" in advance (I think create a window with appropriate location and dimensions and be listening on the gstreamer message bus (which is done) for a message asking if a "context" is available, and immediately provide it. If gstreamer does not get given a "context", it creates one by itself, presumably using the screen on which the uxplay terminal is running as the location.

UxPlay's gstreamer interface is not written by a gstreamer expert, I'm afraid, so the easy choice to let gstreamer handle setting up the window by itself was used....

[mxwmnn]

Okay, got it solved with a little workaround for my specific use case.

It's so specific maybe no one will ever face it. It's not only the konsole window active and in foreground on another display. It seems enough that any application in the foreground and then executing uxplay chooses the display.

I use KDE Connect app to run commands on the pc. The pc is connected to a beamer via HDMI. If i run Kodi (it always open on the Beamer, cause of settings) i can then execute the uxplay command to start the server and it will be served on the beamer hdmi output.

Edit: It doesnt't even depend on the active application, it depends where the mouse is on which display.

And yes screen and display are not synonymous i think, rly complicated

[fduncanh]

Thanks for the useful knowledge input!

[mxwmnn]

Confirmed. Even if firefox on another hdmi output is the active window and the mouse is on the hdmi beamer display i then execute with Kde connect the uxplay command and mirror it appears on the beamer. So it opens where the mouse it.

Thanks for your help. Maybe one time i want to dig more into this stuff. Really interesting and confusing at the same time haha

[fduncanh]

If it depends on where the mouse it (and if xdotool works on XWayland) that the kind of thing xdotool handles.

[thiccaxe]

To further specify, on Wayland Fedora 37 KDE Plasma:

• when you run uxplay program, a wayland application opens
• this application doesn't seem to have any visible windows associated with it.
• when you start a screen mirror, this wayland "application" disappears and is replaced with an X window in the same display as the current location of the mouse at the time when (presumably) Uxplay creates the gstreamer stream. This is not related to the terminal window in which uxplay is run.

Other investigation: considering what might happen in the case that we run uxplay in a non-desktop environment: eg. tty3 for me (Ctrl Alt F3):

• the window is in the same location as before: where the mouse is at the time uxplay creates the window. However, a notable difference is the way that the window is created:

• Instead of an "X" window, we have a seperate "Wayland" window that doesn't have any of the controls that you might expect from Plasma:

• this window can be manipulated using keyboard shortcuts but has no interaction with the mouse.

• • To elaborate on this, when you enter the window area, the cursor that is currently in use (ie, the pointer, zoom, text icon) will remain the same as you move the cursor around the window and only update when the window is left.

• only way I can think of to manipulate windows in a wayland environment is to use Dbus to interact with the window manager. E.G. for Plasma (KWin) you would use for example: dbus-send --session --dest=org.kde.KWin --print-reply --type=method_call /component/kwin org.kde.kglobalaccel.Component.invokeShortcut string:"Window to Screen 1" but of course this is highly dependent on the run time environment etc. (and out of scope for UxPlay, this can be done with user scrips most likely)

[mxwmnn]

Insane! Thank you so much for your effort! Is it possible to buy you a coffee, the dbus command works flawless, so now i don't have to put the mouse on the display :)

[thiccaxe]

Thanks that I was able to help. I found this using Qtdbusviewer application. You can find there a directory of dbus interfaces. If a gnome user is looking to find similar commands he should look in the Qtdbusviewer too.