Emulator

Has anyone seen this report?

I really need Menu access and functionality returned.

I don't understand, or see why Dolphin should be crippling a desktop in Linux like this.

Unless this is fixed, I always have to shutdown Dolphin in order to be able to gain access to the Openbox menu to do something...

I hope this can be fixed...

Thanks

You have a very niche setup that nobody really has so nobody has looked into it. If anything I'd be more inclined to believe this is simply some obscure quirk with your WM.

Well, it's not actually my WM, and Openbox is quite popular in the Linux world, of course true, most still stick to Gnome, KDE, or XFce, but with Cinnamon out there from Mint, it's also happening...

Anyhow, if anyone uses Linux as a Dolphin developer, it would be greatly appreciated to have looked into.

I really love Dolphin and use sometimes at great lengths gaming, but then there are times when I need, or want to jump back and forth and do something, and I have to shut it down.

I will test on this further, with an even more default setup, meaning, the plain vanilla menu.xml, with no changes. Not that I can see why making a menu is going to cause the Right Click function to stop working...

Thank for the reply, greatly appreciated.

Linux is most of the frequent contributors' OS of choice. Nobody uses Slackware.

This is either a bug with your distro or with Wx and your particular, obscure setup. I just loaded up Openbox and Dolphin works fine with right click menu.

Hi Helios,

I took your reply to mean the right click works in Dolphin, not Openbox.

So if this is correct what you meant, I am talking about the Openbox menu, when you right click in Openbox to bring that up...

that is what I meant

Hi Helios,

Ok, I thought I made it clear, I am talking about Right Click on Openbox desktop and the Openbox Menu won't appear.

I also looked online and saw something else had this issue using Awesome in Arch a few years back;

https://bbs.archlinux.org/viewtopic.php?id=196130

I dug through the source a little and came up with the rc.xml which is the main control of this that I can see placed under;

~/.config/openbox/rc.xml and I noticed these 4 sections, the last one I did not touch. For the first 3, I removed the mousebind button and action, 'Right' and 'Press' from the code and the Menu did not work, appear in Openbox.

Doing a grep into the code I found this as well;

client_menu.c:#define CLIENT_MENU_NAME "client-menu"

Line - 556

Line - 591

Line - 632

Line - 755 - ( I didn't touch this one)

Sorry I placed XML code in that last reply and it didn't appear...

Starting at line 556 and Line 591, and line 632 it looks like this below minus the xml code;

mousebind button="Right" action="Press"
action name="Focus"
action name="Raise"
action name="ShowMenu"
menu client-menu menu
action
mousebind

Line 755 looks like this;

mousebind button="Right" action="Press"
action name="ShowMenu"
menu root-menu menu
action
mousebind

But how is this Dolphin's responsibility? Am I missing something...? Isn't it Openbox's responsibility?

Openbox is compliant with the Inter-Client Communication Conventions Manual (ICCCM) and Extended Window Manager Hints (EWMH).

So what are we saying, that Dolphin is going beyond these standards, into something new that Openbox lacks support for?

All I know as an end-user is that Dolphin locks/freezes the desktop in Openbox, so you loose it's functionality...

Who's responsibility, well...

I'll submit a bug report to Openbox and see if I get any response from them over this...

I'm not familiar enough to know where the bug lies. Maybe the Qt GUI will avoid whatever is happening.

Here is the Openbox bug report to follow, or for anyone to submit any information they have...

https://bugzilla.icculus.org/show_bug.cgi?id=6490

@JMC4789, did you see the Arch link I posted, someone had the same issue in Awesome;

https://bbs.archlinux.org/viewtopic.php?id=196130

Also WX the last I look was the default, has it now gone to QT?

Qt isn't the default yet, but we hope it will be the default in a not too distant future.

I ran xev to watch events on the root window and see if a click creates anything, but xev shows no input when I click on the desktop to try and bring up the menu...

Can we please look into this and get a fix for it? This appears to be a bug in Dolphin.

Thanks

Has anyone had a chance to look at this?

I just grabbed yesterday dolphin-5.0.8512 which is using QT5 and I still see the same problem.

I really need to use my desktop, but I can't with dolphin running... :(

Thanks

I just compiled 5.0.10910 using QT5 5.9.8 and it's still doing the same thing, can't use the Menu in Openbox....

Can someone please tell me if they know anything about this, and it can be fixed here soon please?

THANKS

Still no idea what's going on here, but I have at least reproduced it, confirming it's not some configuration-specific thing.

I'm also having this problem. It still occurs when using dolphin-emu-nogui, so it may not be directly related to Qt.

Dolphin 5.0-15445 (db02b50d2e), built by Arch; same issue with current master d9e0bf72dcc2cf built by myself
Openbox 3.6.1
Qt 5.15.2+kde+r297-2
xorg-server 21.1.3-2
not using a compositor
Arch Linux kernel 5.16.8-arch1-1
Ryzen 2200G (using the integrated GPU with the amdgpu driver)

If I go into the controller configuration dialog and click one of the '...' buttons to get to the formula editor, with the dropdown set to "[default] XInput2/0/Virtual core pointer", and scroll so that "Click 1" is visible, then when I click on the root window (desktop), the input is registered in the dialog (the 0 becomes a 1 with red background). Clicking in Dolphin or in other applications, regardless of which application has the focus, does not register. The "Background Input" checkbox does not affect the behavior.

Issue #8469 is another report from 2015.

I don't know much about X, but I have successfully built Dolphin and am willing to help debug.

Hello,

I'm still having this problem 5 years later. :(

Can we PLEASE get someone to install Openbox on a distro and test this, or test this on Slackware 15.0, with Openbox and see if you can please fix this?

I can't use the desktop if dolphin is running, it's really frustrating having to close it and restart it, if I want to do something else while dolphin is running.

These are my specs now at present;

Dolphin 5.0.19115
Slackware 15.0 x64
Ryzen 5 5600X
GTX 3080
27" 2560x1440
Ram 32GB DDR4 3200mhz
Openbox 3.6.1
tint2-17.0.2
picom-10.2 (composite manager)
nvidia-driver-525.78.01
xorg-server-1.20.14
Nyko Core PS3 controller

THANKS

I would of edited my last reply, but there doesn't seem to be an edit function for this.

I forgot to mention Slackware 15.0 uses; qt5-5.15.3

THANKS

SORRY, forgot to also mention, no mouse buttons work at all, left, middle, right etc., when dolphin is running.

I just wanted to make that clear, it's not just a 'right click' issue.

THANKS

I still don't know much about X, but after some experimentation I have a hypothesis that matches the observed behavior with Openbox. I don't think it is a Dolphin-specific issue, because running xinput --test-xi2 --root in a terminal emulator also prevents Openbox from handling clicks/scrolling on the root window.

Dolphin and xinput use XInput2 and select for XI_ButtonPress events. When both Dolphin and xinput are running and watching the root window, they both receive XI_ButtonPress events. Openbox does not use XInput (no hits for "XInputExtension" or "XIQueryVersion" in the Openbox code 0), so it selects for "core" (legacy X11) ButtonPress events. Apparently, only one client per X11 window can select for ButtonPress events. This is stated in two places in X11 documentation 1 and might be related to a server-generated active grab 3. Thus, my hypothesis is that any client selecting for XI_ButtonPress suppresses core ButtonPress events, to emulate the single-client restriction.

If Dolphin doesn't select for XI_ButtonPress (by commenting out XISetMask(mask_buf, XI_ButtonPress) 4), and xinput is not running, Openbox can handle clicks on the root window. Of course, that means Dolphin doesn't see clicks. Dolphin could select for XI_RawButtonPress instead, but that will contain an "unmapped" button number 5.

The remaining question is why other desktop environments/window managers don't have this problem. I'm not familiar with any of them, but they're all newer than Openbox (except maybe fluxbox?), so they would use XInput2 for its new features and also dodge this issue. For DEs in particular, it's possible they create fullscreen windows above the root window to display icons/wallpaper/etc., and so even if they're using core ButtonPress there's no conflict with Dolphin. And possibly other things.

General references:

The XInput2 specification: https://www.x.org/releases/X11R7.7/doc/inputproto/XI2proto.txt
XOrg release manager blog's XInput2 tag: https://who-t.blogspot.com/search/label/xi2

On Openbox, button press delivery is mostly broken. Dolphin only acts on clicks if the pointer is over the root window or window decorations (window title bars). If background input is unchecked, the render window additionally has to have the focus. Clicks when the pointer is over the render window, game list window, or other applications (when background input is checked) are not received (or received but not processed?). In particular, in the controller configuration dialog, inputs can only be assigned to mouse buttons by clicking the input's GUI button and then clicking on the root window or window decorations, and once assigned, the input is only bolded by clicking in the same areas.

I installed enough of GNOME to launch Mutter/gnome-session via startx. Button press delivery works as expected in the controller configuration dialog and during gameplay, including clicks on most other application windows when background input is checked. The exception is if the click occurs when the pointer is over the window created by xinput --test-xi2 (without --root); those clicks are not delivered. Presumably other XInput2-aware applications might also interfere. Mutter doesn't use the root window. Instead the desktop background is a window named "mutter guard window". Mutter does not set the WM hint X11 properties to make the guard window a virtual root window, but it seems to serve a similar function.

I expect any window manager that uses the real root window to have similar problems. The previously mentioned duplicate issue #8469 mentions awesome; another duplicate I just found, issue #12092, mentions twm, ctwm, fvwm, and fluxbox (not sure if all were tested, or just given as examples of WMs using the real root).

I think the fix is to subscribe to raw button events and do the button mapping ourselves. While searching I found some Chromium code that does mapping after listening to mapping update events 1 and this code is called when processing XInput2 events 2. I don't know why Chromium needs XInput2, but given they're doing it, manual mapping seems like a plausible thing for us to do. We need to ask for XInput 2.1 or above (currently using 2.0) to get raw mouse events even if another client has a grab, including the implicit grab from a button press. This should fix both the Openbox/etc interference and the potential interference from other XInput2 applications.

I found confirmation of my hypothesis from comment 24 in a blog post from the XInput developer 1:

When the event passes through the master device, it updates the master's internal state and is then delivered to the client. Delivery happens either as core event, as XI 1.x event or as XI2 event. The same event may be delivered to multiple clients (for example if two or more clients registered the same event mask on the same window), but once delivered the event cannot be delivered as a different event category.

Hi jbosboom,

It's great to finally hear from someone. I really love dolphin, it runs amazing in Linux, but I only run Openbox.

From what I've read, it sounds like something can be implemented to correct this in the future?

THANK you very much!

I opened a pull request: https://github.com/dolphin-emu/dolphin/pull/11762

Is this issue now resolved with the merge of that PR in 5.0-19540 or later?

Yes, this issue is resolved. (Just checked again with Arch's build of 5.0-20347.)