Nucleus Co-Op (previously known as Universal Split Screen)

d.ALT · 2021-11-02 12:08:45

I'm looking for a way to handle multiple inputs (see title, Windows only).
In Xorg this would be referenced to as multiseat, right?

I'll try to explain better, and please let me know if what I'm asking is actually achieved via multiseat capability.
Or should I look for a Xephyr setup???
Please correct me if I'm wrong...

Let's say I'm running simultaneously two (or more) separate instances of the same program.
- > there would be any differences between starting them from the same executable or not?
- > eg.: /usr/bin/sameprogram_A && /usr/bin/sameprogram_A VS /usr/bin/sameprogram_A && /usr/bin/sameprogram_B
Joystick in the 1st instance is configured as Player1 and mapped as /dev/input/js0
Joystick in the 2nd instance is configured as Player1 and mapped as /dev/input/js1
If click the window of 1st instance, it gains focus and I can play using /dev/input/js0
But, when clicking the window of 2nd instance, it gains focus and I can play using /dev/input/js1, but I'm loosing the 1st instance

How can I achieve having focus on both window's instances at the same time?
Can I use both the two different inputs (js0 and js1) each one bind to its instance?

Thanks

Last edited by d.ALT (2021-11-02 12:27:40)

Trilby · 2021-11-02 13:13:22

Often game programs will allow you to specify which input to use. In this case you would not need multiseat / xephyr - just run two instances of the game in question each one with the appropriate flags or configs to specify the desired input.

If the "someprogram" doesn't have any such options, then multiseat / xephyr would likely be the easiest approach. But what is "someprogram"? Hypothetical threads are rarely productive as they often reveal themselves to be X-Y problems. Do you have multiple monitors and keyboards that you intend to use? If not, then you do not want multiseat.

Last edited by Trilby (2021-11-02 13:24:51)

d.ALT · 2021-11-02 19:22:18

Hey Trilby, thanks taking your time answering me.

Trilby wrote:

Do you have multiple monitors and keyboards that you intend to use? If not, then you do not want multiseat.

Nope: only one monitor and only one keyboard... But I have two joysticks.

So, the program is Supermodel emulator, which was compiled manually from svn.
I then copied the generated linked bin (./supermodel) into both /Supermodel-master/supermodel_A and /Supermodel-slave/supermodel_B.
Is it possible to specify which input to use in its config file (Supermodel.ini) and that's what I've done, but there's a caveat, please keep readin' on...
In order to play (network)linked game, there must be running simultaneously two dedicate emulator's instances of the same game:

1st instance ($ ./supermodel_A) is launched and game's internal configuration is setup as "LINK TYPE = MASTER(CAR1)"
2st instance ($ ./supermodel_B) is launched and this time game's internal configuration is instead setup as "LINK TYPE = SLAVE (CAR2)"

And here's the caveat: each one emulator's instance runs from its own dedicated directory with its own dedicated config (let's call 'em Supermodel_A.ini and Supermodel_B.ini).
That's how it works, there's no other way.

Let's tidy up a bit:

/Supermodel-master/supermodel_A ###executable
/Supermodel-master/Config/Supermodel.ini ###config file relative to supermodel_A
	/dev/input/js0 is JOY1 which is mapped as P1
	SimulateNet = 1
	Network = 1
	PortIn = 1970
	PortOut = 1971
	AddressOut = "127.0.0.1"

--

/Supermodel-slave/supermodel_B ###executable
/Supermodel-slave/Config/Supermodel.ini ###config file relative to supermodel_B
	/dev/input/js1 is JOY2 which is mapped as P1
	SimulateNet = 1
	Network = 1
	PortIn = 1971
	PortOut = 1970
	AddressOut = "127.0.0.1"

In conclusion, focusing on one instance's window (or to the other) means controlling only one input at a time.

Last edited by d.ALT (2021-11-02 19:26:47)

Trilby · 2021-11-02 21:50:24

Ah, so it sounds like you've solved everything except allowing both client windows to get input (focus) at the same time, right?

I'm not sure if / how that'd be possible under X11 other than having another process running, capturing actual input events then dispatching synthetic events to each of the two target clients (games). In other words, I don't think there is any "generic" way to achieve your goal; instead you'd have to find (or write) a tool specifically for this task.

d.ALT · 2021-11-03 18:48:27

Trilby wrote:

Ah, so it sounds like you've solved everything except allowing both client windows to get input (focus) at the same time, right?

Exactly.

Trilby wrote:

Ah, so it sounds like you've solved everything except allowing both client windows to get input (focus) at the same time, right?
I'm not sure if / how that'd be possible under X11 other than having another process running, capturing actual input events then dispatching synthetic events to each of the two target clients (games). In other words, I don't think there is any "generic" way to achieve your goal; instead you'd have to find (or write) a tool specifically for this task.

Ok, thanks for your interest.

progandy · 2021-11-03 22:30:42

Maybe it would be enough to create a second x cursor and somehow move it to the second window and click on it. (moving that cursor would be easiest with a second mouse assigned to it) Maybe that will proviude just enough of a focus to read joystick events.
https://wiki.archlinux.org/title/Multi-pointer_X

Last edited by progandy (2021-11-03 22:33:01)

d.ALT · 2021-11-05 11:38:54

progandy wrote:

Maybe it would be enough to create a second x cursor and somehow move it to the second window and click on it. (moving that cursor would be easiest with a second mouse assigned to it) Maybe that will proviude just enough of a focus to read joystick events.
https://wiki.archlinux.org/title/Multi-pointer_X

Mmm... Interesting. I need to check if / how to handle together two mouse pointers with only one hardware input device (I'm currently using a keyboard+mouse combo: Logitech K400+).

Arch Linux

#1 2021-11-02 12:08:45

Nucleus Co-Op (previously known as Universal Split Screen)

#2 2021-11-02 13:13:22

Re: Nucleus Co-Op (previously known as Universal Split Screen)

#3 2021-11-02 19:22:18

Re: Nucleus Co-Op (previously known as Universal Split Screen)

#4 2021-11-02 21:50:24

Re: Nucleus Co-Op (previously known as Universal Split Screen)

#5 2021-11-03 18:48:27

Re: Nucleus Co-Op (previously known as Universal Split Screen)

#6 2021-11-03 22:30:42

Re: Nucleus Co-Op (previously known as Universal Split Screen)

#7 2021-11-05 11:38:54

Re: Nucleus Co-Op (previously known as Universal Split Screen)

Board footer