GTK-UI: No menu on right-click on Fedora 34

Describe the bug

Right-click menu doesn't pop up.

My problem has very similar symptoms to #240, except I have GTK3 devel packages installed, and they seem to be found during build. But, when running xmega65.native, right-click does nothing.

There is one related warning during build, but it's just a deprecation warning, and I don't think it explains the problem. That warning is:

In file included from ../../xemu/emutools_gui.c:56:
../../xemu/gui/gui_gtk.c: In function ‘xemugtkgui_popup’:
../../xemu/gui/gui_gtk.c:395:9: warning: ‘gtk_menu_popup’ is deprecated: Use '(gtk_menu_popup_at_widget, gtk_menu_popup_at_pointer, gtk_menu_popup_at_rect)' instead [-Wdeprecated-declarations]
  395 |         gtk_menu_popup(
      |         ^~~~~~~~~~~~~~
In file included from /usr/include/gtk-3.0/gtk/gtklabel.h:34,
                 from /usr/include/gtk-3.0/gtk/gtkaccellabel.h:35,
                 from /usr/include/gtk-3.0/gtk/gtk.h:33,
                 from ../../xemu/gui/gui_gtk.c:30,
                 from ../../xemu/emutools_gui.c:56:
/usr/include/gtk-3.0/gtk/gtkmenu.h:138:12: note: declared here
  138 | void       gtk_menu_popup                 (GtkMenu             *menu,
      |            ^~~~~~~~~~~~~~

This is a build from source (master branch checked out today) on Fedora 34, fully up to date, with all the build dependencies that I'm aware of, and I can see gtk being detected and allegedly initialized when starting xmega65.native:

GUI: no GUI was specified, using the first available one from this list: gtk none
GUI: using "gtk" (GTK3 based Xemu UI implementation)
GUI: GTK3 initialized, 9 iterations.

Used version of the project

VERSION: https://github.com/lgblgblgb/xemu.git master 51ab5016d0de96512f951f98c8f839d76854cd5e 20210923194739 custom-build

To Reproduce

Build the master branch on Fedora 34
Run mega65.native
Right-click...nothing happens.

Expected behavior

Menu appears on right-click.

Computer/Device (please complete the following information):

Device/Platform: Intel x86_64 PC
OS and its version: Fedora 34

Additional context

First of all, thanks for the report.

Indeed, it seems it's not #240 as the message you've quoted from Xemu's output shows that GTK3 is initialized (so it's surely compiled in, unlike in that issue). Also the compilation time warning confirms that. That warning is harmless, it's a conceptional problem that GTK want to obsolete a feature I couldn't do this otherwise ... No idea what would happen when it's totally removed, and not only obsoleted (ie, the mouse click happens in SDL yet, nothing to do with GTK, but the menu is GTK).

Honestly not so much idea yet about the problem (needless to say, never see or heard or reported an issue like this), I don't have Fedora, and unfortunately not even a real possibility to try for me (with my unfortunate situation that I have a seriously underpowered PC and lack of disk space even for a decent VM, for that matter. Sorry for the off-topic).

My first guess: there is some serious misunderstanding somewhere what is the current used display and how to access it. Just a wild guess, but maybe SDL uses X11 protocol, but your Fedora is Wayland based and GTK is natively uses Wayland, or vice-versa, really I have not so much a detailed explanation for this, just my gut feeling. Just for testing you may try to have a desktop session with classic Xorg (or using Wayland, if it was Xorg already). As far as I remember, newer Fedora versions uses Wayland by default (I never had Fedora, so I just read news about it, last time I even had RedHat - or kind of derived distros in general - was in 1996 - RedHat Colgate - or so ...).

The other useful thing, if you can please provide the full output of Xemu in form of text file, it may say things later when you try to click for the menu (among other messages which may or may not be useful).

Thanks for the quick reply!

Just a wild guess, but maybe SDL uses X11 protocol, but your Fedora is Wayland based and GTK is natively uses Wayland, or vice-versa, really I have not so much a detailed explanation for this, just my gut feeling.

This seems plausible. I don't even know which one I'm using at this point...I'd forced it to use X11 in the past because Wayland didn't work with something I needed, but I don't remember what, and I've upgraded Fedora major versions at least twice since then...I would not be at all surprised if it switched back to Wayland. If it's still possible to switch between them, I'll try both and get back to you.

I don't see anything related to the mouse clicks in the console, but F keys also don't work right with these errors for F3 and F4 (and others don't seem to do anything):

The key you just pressed is not recognized by SDL. To help get this fixed, please report this to the SDL forums/mailing list <https://discourse.libsdl.org/> X11 KeyCode 128 (120), X11 KeySym 0x1008FF4A (XF86LaunchA).
The key you just pressed is not recognized by SDL. To help get this fixed, please report this to the SDL forums/mailing list <https://discourse.libsdl.org/> X11 KeyCode 212 (204), X11 KeySym 0x1008FF4B (XF86LaunchB).

Anyway, here's the full output, but it doesn't seem to change anything when clicking the mouse in the window:

**** The Evolving MEGA65 emulator from LGB ****
This software is part of the Xemu project: https://github.com/lgblgblgb/xemu
CREATED: joe@localhost.localdomain on Linux 5.13.16-200.fc34.x86_64 at Fri Sep 24 05:06:46 PM CDT 2021
CREATED: gcc-compatible 11.2.1 20210728 (Red Hat 11.2.1-1) 64LE for linux
VERSION: https://github.com/lgblgblgb/xemu.git master 51ab5016d0de96512f951f98c8f839d76854cd5e 20210923194739 custom-build
EMULATE: MEGA65 (mega65): xmega65 (../../build/bin/xmega65.native) for mega65 on linux (native) using cc
LICENSE: Copyright (C)2016-2021 Gábor Lénárt (aka LGB) lgb@lgb.hu http://lgb.hu/
LICENSE: This software is a GNU/GPL version 2 (or later) software.
LICENSE: <http://gnu.org/licenses/gpl.html>
LICENSE: This is free software; you are free to change and redistribute it.
LICENSE: There is NO WARRANTY, to the extent permitted by law.

FILE: @mega65-default.cfg cannot be open, tried path(s):  /home/joe/.local/share/xemu-lgb/mega65/mega65-default.cfg
CFG: Default config file @mega65-default.cfg cannot be used
CFG: CLI parsing is done without error.
FILE: file @mega65-template.cfg.TMP opened as /home/joe/.local/share/xemu-lgb/mega65/mega65-template.cfg.TMP with base mode-set as fd=5
FILE: 6175 bytes saved into file: @mega65-template.cfg.TMP
FILE: renaming file: /home/joe/.local/share/xemu-lgb/mega65/mega65-template.cfg.TMP -> /home/joe/.local/share/xemu-lgb/mega65/mega65-template.cfg
XEMU: emulated MEGA65 model ID: 255
INSTALLER: not activated.
WARNING: *** NEW M65 HACK MODE ACTIVATED ***
Logging into file: not enabled.
SDL: no SDL subsystem initialization has been done yet, do it!
SDL version: (https://github.com/libsdl-org/SDL.git@25f9ed87ff6947d9576fc9d79dee0784e638ac58) compiled with 2.0.16, used with 2.0.16 on platform Linux
SDL system info: 64 bits LE, 16 cores, l1_line=64, RAM=32014Mbytes, max_alignment=16, CPU features: 3DNow=0 AVX=1 AVX2=1 AltiVec=0 MMX=1 RDTSC=1 SSE=1 SSE2=1 SSE3=1 SSE41=1 SSE42=1
SDL drivers: video = x11, audio = pulseaudio
TIMING: sleep = nanosleep, query = SDL_GetPerformanceCounter
SDL preferences directory: /home/joe/.local/share/xemu-lgb/mega65/
SDL window native pixel format: SDL_PIXELFORMAT_RGB888
SDL renderer driver #3: "software"
SDL renderer driver #2: "opengles"
SDL renderer driver #1: "opengles2"
SDL renderer driver #0: "opengl"
SDL renderer used: "opengl" max_tex=16384x16384 tex_formats=8 (SDL_PIXELFORMAT_ARGB8888 SDL_PIXELFORMAT_ABGR8888 SDL_PIXELFORMAT_RGB888 SDL_PIXELFORMAT_BGR888 SDL_PIXELFORMAT_YV12 SDL_PIXELFORMAT_IYUV SDL_PIXELFORMAT_NV12 SDL_PIXELFORMAT_NV21)
SDL: creating main texture 800 x 625

GUI: no GUI was specified, using the first available one from this list: gtk none
GUI: using "gtk" (GTK3 based Xemu UI implementation)
GUI: GTK3 initialized, 9 iterations.
FILE: file @keymap-default.cfg opened as /home/joe/.local/share/xemu-lgb/mega65/keymap-default.cfg with base mode-set as fd=23
HID: 89 key bindings has been added as the default built-in configuration
FILE: @keymap.cfg cannot be open, tried path(s):  /home/joe/.local/share/xemu-lgb/mega65/keymap.cfg
HID: cannot open keymap user config file (maybe does not exist), ignoring: @keymap.cfg
BIN: config "loadrom" as "C65 ROM image": pre-zero policy, clearing memory content.
BIN: config "loadrom" as "C65 ROM image": has no option override, using the previously stated policy.
BIN: config "loadcram" as "CRAM utilities": no pre-zero policy, using some (possible) built-in default content.
BIN: config "loadcram" as "CRAM utilities": has no option override, using the previously stated policy.
BIN: config "loadbanner" as "M65 logo": no pre-zero policy, using some (possible) built-in default content.
BIN: config "loadbanner" as "M65 logo": has no option override, using the previously stated policy.
BIN: config "loadc000" as "C000 utilities": pre-zero policy, clearing memory content.
BIN: config "loadc000" as "C000 utilities": has no option override, using the previously stated policy.
BIN: config "kickup" as "M65 kickstart": no pre-zero policy, using some (possible) built-in default content.
BIN: config "kickup" as "M65 kickstart": has no option override, using the previously stated policy.
FILE: file @nvram.bin opened as /home/joe/.local/share/xemu-lgb/mega65/nvram.bin with base mode-set as fd=24
FILE: 64 bytes loaded from file: /home/joe/.local/share/xemu-lgb/mega65/nvram.bin
FILE: file @uuid.bin opened as /home/joe/.local/share/xemu-lgb/mega65/uuid.bin with base mode-set as fd=37
FILE: 8 bytes loaded from file: /home/joe/.local/share/xemu-lgb/mega65/uuid.bin
D81: initial subsystem reset
SDCARD: configuring F011 FDC (#0) with have_disk=0, can_write=1
SDCARD: configuring F011 FDC (#1) with have_disk=0, can_write=1
FILE: file @mega65.img opened as /home/joe/.local/share/xemu-lgb/mega65/mega65.img with base mode-set as fd=24
SDCARD: image is not compressed
SDCARD: card init done, size=128 Mbytes, virtsd_flag=0
SDCARD: check Xemu signature (@block 2): disk=0 this_xemu=1
INFO: Cannot find Xemu's signature on the SD-card image.
Please use UI menu: SD-card -> Update files ...
UI can be accessed with right mouse click into the emulator window.
SPEED: CPU speed is set to 1MHz, cycles per scanline: 32 in <UNDEF> (1MHz cycles per scanline: 32.000000)
VIC: Write $0058 LINESTEP: $00
VIC: Write $0059 LINESTEP: $00
VIC: Write $005d SIDEBORDER/HOTREG: $00
VIC: Write $005e CHARCOUNT: $00
VIC: Write 0xD030: $00
DMA: 'hack' (preliminary!! support for new-style M65 DMA) status: **ENABLED**
DMA: initializing DMA engine for chip revision 1 (initially, may be modified later!), dyn_mode=YES(M65-aware), modulo_support=DISABLED.
D81: attach file request with empty file name, not using FS based disk attachment.
UARTMON: disabled, no name is specified to bind to.
SPEED: fast clock is set to 40.50MHz.
CPU[65CE02]: RESET, PC=0000, BCD_behaviour=NMOS-6502
SPEED: CPU speed is set to 40.50MHz, cycles per scanline: 1296 in <UNDEF> (1MHz cycles per scanline: 32.000000)
SPEED: in_hypervisor=1 force_fast=0 c128_fast=0, c65_fast=0 m65_fast=0
SPEED: CPU speed is set to 40.50MHz, cycles per scanline: 1296 in <UNDEF> (1MHz cycles per scanline: 32.000000)
AUDIO: reset for 4 SIDs (1000000 cycles per sec) and 1 OPL3 chip for 44100Hz sampling rate.
AUDIO: clearing audio related registers.
AUDIO: initialized (#2), 44100 Hz, 2 channels, 1024 buffer sample size.
AUDIO: volume is set to 100%, stereo separation is 60% [component-A is 80, component-B is 20]
MEM: UNHANDLED memory policy: 0
ETH: not enabled by config/command line
UMON: not enabled
AUDIO: start mixing.
VIC: switching video standard from <UNDEF> to PAL (1MHz line cycle count is 32.000000, frame time is 20000usec, max raster is 624, visible area height is 576)
AUDIO: callback switches to working mode.
SPEED: CPU speed is set to 40.50MHz, cycles per scanline: 1296 in PAL (1MHz cycles per scanline: 32.000000)
VIC: Write $005d SIDEBORDER/HOTREG: $c0
VIC4: set border left=14, right=782, textxpos=0
VIC4: set border left=94, right=702, textxpos=0
VIC4: set border left=94, right=702, textxpos=0
VIC4: set border top=112, bottom=498, textypos=98, display_row_count=24 vic_ii_first_raster=0 EFFECTIVE_V400=0 REG_V400=0
VIC4: 16bit=1, chrcount=40, linestep=40 bytes, charxscale=120, ras_src=0 screen_ram=$000400, charset/bitmap=$001000, sprite=$0007f8
VIC4: set border left=94, right=702, textxpos=80
VIC4: set border top=104, bottom=504, textypos=104, display_row_count=25 vic_ii_first_raster=0 EFFECTIVE_V400=0 REG_V400=0
VIC4: 16bit=1, chrcount=40, linestep=40 bytes, charxscale=120, ras_src=0 screen_ram=$000400, charset/bitmap=$001000, sprite=$0007f8
VIC4: set border left=80, right=719, textxpos=80
VIC4: set border top=104, bottom=504, textypos=104, display_row_count=25 vic_ii_first_raster=0 EFFECTIVE_V400=0 REG_V400=0
VIC4: 16bit=1, chrcount=40, linestep=40 bytes, charxscale=120, ras_src=0 screen_ram=$000400, charset/bitmap=$001000, sprite=$0007f8
VIC: Write $0058 LINESTEP: $50
VIC: Write $0059 LINESTEP: $00
SDL: auto-resizing window to 705 x 576 (zoom level approximated: 1)
VIC: switching video standard from PAL to NTSC (1MHz line cycle count is 31.777809, frame time is 16683usec, max raster is 526, visible area height is 480)
SPEED: CPU speed is set to 40.50MHz, cycles per scanline: 1287 in NTSC (1MHz cycles per scanline: 31.777809)
SDCARD: D81: mount register request @ $D68B val=$00 at PC=$A1A7
SDCARD: configuring F011 FDC (#0) with have_disk=0, can_write=1
VIC: Write $0058 LINESTEP: $50
VIC: Write $005d SIDEBORDER/HOTREG: $c0
VIC4: set border left=80, right=719, textxpos=80
VIC: Write $0058 LINESTEP: $50
VIC: Write $0059 LINESTEP: $00
SDCARD: D81: mount register request @ $D68B val=$00 at PC=$A1A7
SDCARD: configuring F011 FDC (#0) with have_disk=0, can_write=1
VIC: Write $0058 LINESTEP: $50
SDL: auto-resizing window to 705 x 480 (zoom level approximated: 1)
VIC: Write $005d SIDEBORDER/HOTREG: $c0
VIC4: set border left=80, right=719, textxpos=80
VIC: Write $0058 LINESTEP: $50
VIC: Write $0059 LINESTEP: $00
SDCARD: D81: mount register request @ $D68B val=$00 at PC=$A1A7
SDCARD: configuring F011 FDC (#0) with have_disk=0, can_write=1
VIC: Write $0058 LINESTEP: $50
VIC: Write $005d SIDEBORDER/HOTREG: $c0
VIC4: set border left=80, right=719, textxpos=80
VIC: Write $0058 LINESTEP: $50
VIC: Write $0059 LINESTEP: $00
SDCARD: D81: mount register request @ $D68B val=$00 at PC=$A1A7
SDCARD: configuring F011 FDC (#0) with have_disk=0, can_write=1
VIC: Write $0058 LINESTEP: $50
VIC: Write $005d SIDEBORDER/HOTREG: $c0
VIC4: set border left=80, right=719, textxpos=80
VIC: Write $0058 LINESTEP: $50
VIC: Write $0059 LINESTEP: $00
SDCARD: D81: mount register request @ $D68B val=$00 at PC=$A1A7
SDCARD: configuring F011 FDC (#0) with have_disk=0, can_write=1
VIC: Write $0058 LINESTEP: $50
VIC: Write $005d SIDEBORDER/HOTREG: $c0
VIC4: set border left=80, right=719, textxpos=80
VIC: Write $0058 LINESTEP: $50
VIC: Write $0059 LINESTEP: $00
SDCARD: D81: mount register request @ $D68B val=$00 at PC=$A1A7
SDCARD: configuring F011 FDC (#0) with have_disk=0, can_write=1
VIC: Write $0058 LINESTEP: $50
VIC: Write $005d SIDEBORDER/HOTREG: $c0
VIC4: set border left=80, right=719, textxpos=80
VIC: Write $0058 LINESTEP: $50
VIC: Write $0059 LINESTEP: $00
SDCARD: D81: mount register request @ $D68B val=$00 at PC=$A1A7
SDCARD: configuring F011 FDC (#0) with have_disk=0, can_write=1
VIC: Write $0058 LINESTEP: $50
VIC: Write $005d SIDEBORDER/HOTREG: $c0
VIC4: set border left=80, right=719, textxpos=80
VIC: Write $0058 LINESTEP: $50
VIC: Write $0059 LINESTEP: $00
SDCARD: D81: mount register request @ $D68B val=$00 at PC=$A1A7
SDCARD: configuring F011 FDC (#0) with have_disk=0, can_write=1
VIC: Write $0058 LINESTEP: $50
VIC: Write $005d SIDEBORDER/HOTREG: $c0
VIC4: set border left=80, right=719, textxpos=80
VIC: Write $0058 LINESTEP: $50
VIC: Write $0059 LINESTEP: $00
SDCARD: D81: mount register request @ $D68B val=$00 at PC=$A1A7
SDCARD: configuring F011 FDC (#0) with have_disk=0, can_write=1
VIC: Write $0058 LINESTEP: $50
VIC: Write $005d SIDEBORDER/HOTREG: $c0
VIC4: set border left=80, right=719, textxpos=80
VIC: Write $0058 LINESTEP: $50
VIC: Write $0059 LINESTEP: $00
SDCARD: D81: mount register request @ $D68B val=$00 at PC=$A1A7
SDCARD: configuring F011 FDC (#0) with have_disk=0, can_write=1
VIC: Write $0058 LINESTEP: $50
VIC: Write $005d SIDEBORDER/HOTREG: $c0
VIC4: set border left=80, right=719, textxpos=80
VIC: Write $0058 LINESTEP: $50
VIC: Write $0059 LINESTEP: $00
SDCARD: D81: mount register request @ $D68B val=$00 at PC=$A1A7
SDCARD: configuring F011 FDC (#0) with have_disk=0, can_write=1
VIC: Write $0058 LINESTEP: $50
VIC: Write $005d SIDEBORDER/HOTREG: $c0
VIC4: set border left=80, right=719, textxpos=80
VIC: Write $0058 LINESTEP: $50
VIC: Write $0059 LINESTEP: $00
SDCARD: D81: mount register request @ $D68B val=$00 at PC=$A1A7
SDCARD: configuring F011 FDC (#0) with have_disk=0, can_write=1
VIC: Write $0058 LINESTEP: $50
VIC: Write $005d SIDEBORDER/HOTREG: $c0
VIC4: set border left=80, right=719, textxpos=80
VIC: Write $0058 LINESTEP: $50
VIC: Write $0059 LINESTEP: $00
SDCARD: D81: mount register request @ $D68B val=$00 at PC=$A1A7
SDCARD: configuring F011 FDC (#0) with have_disk=0, can_write=1
VIC: Write $0058 LINESTEP: $50
The key you just pressed is not recognized by SDL. To help get this fixed, please report this to the SDL forums/mailing list <https://discourse.libsdl.org/> X11 KeyCode 128 (120), X11 KeySym 0x1008FF4A (XF86LaunchA).
The key you just pressed is not recognized by SDL. To help get this fixed, please report this to the SDL forums/mailing list <https://discourse.libsdl.org/> X11 KeyCode 212 (204), X11 KeySym 0x1008FF4B (XF86LaunchB).
VIC: Write $005d SIDEBORDER/HOTREG: $c0
VIC4: set border left=80, right=719, textxpos=80
VIC: Write $0058 LINESTEP: $50
VIC: Write $0059 LINESTEP: $00
SDCARD: D81: mount register request @ $D68B val=$00 at PC=$A1A7
SDCARD: configuring F011 FDC (#0) with have_disk=0, can_write=1
VIC: Write $0058 LINESTEP: $50
VIC: Write $005d SIDEBORDER/HOTREG: $c0
VIC4: set border left=80, right=719, textxpos=80
VIC: Write $0058 LINESTEP: $50
VIC: Write $0059 LINESTEP: $00
SDCARD: D81: mount register request @ $D68B val=$00 at PC=$A1A7
SDCARD: configuring F011 FDC (#0) with have_disk=0, can_write=1
VIC: Write $0058 LINESTEP: $50
VIC: Write $005d SIDEBORDER/HOTREG: $c0
VIC4: set border left=80, right=719, textxpos=80
VIC: Write $0058 LINESTEP: $50
VIC: Write $0059 LINESTEP: $00
SDCARD: D81: mount register request @ $D68B val=$00 at PC=$A1A7
SDCARD: configuring F011 FDC (#0) with have_disk=0, can_write=1
VIC: Write $0058 LINESTEP: $50
SDCARD: configuring F011 FDC (#0) with have_disk=0, can_write=1
SDCARD: configuring F011 FDC (#1) with have_disk=0, can_write=1
ETH: shutting down: handler thread seems hasn't been even running (not enabled?)

TIMING: Xemu CPU usage: avg=11.71%, min=10%, max=50% (749 counts), uptime=00:15
XEMU: good by(T)e.

Works if I run it under X11 instead of Wayland! Good catch.

So, I guess the "bug" is that maybe SDL isn't doing the right thing on Wayland? I think I've used some other SDL apps that act right, but I'm not super confident about that. I'll leave it up to you as to whether it's something you can address in xemu or if it needs to be kicked up the stack to SDL or Wayland or somewhere else.

Thanks for the hint that got it working for me. For now, I'll just restart in X11 whenever I want to tinker with xemu. Might be worth adding a note for others who might run into this.

That "not recognized key" message is very interesting. It's from SDL itself (so I cannot do anything against that), and I think it's very strange that keys like F3, F4 seems to be "unknown" for libsdl2. There must be some serious issue going on, I don't want to blame your system for sure, but it's really suspect for me, that something is very not OK there. Though I don't know how mature SDL2's relationship (version 2.0.16 it seems what you're using from the output you've posted) with Wayland ...

When you posted this message above (full output from Xemu from start to exit) have you've tried to click meanwhile? Since it may also produce some messages. Also I'm curious if you had any dialog box shown while having this problem (ie at time when you exit it asks if you really want to exit), and if so, what kind of box (if you can judge that by its look), SDL or GTK based.

Ok, now it's the point when I realized you posted another comment here meanwhile :) Hmm, interesting. So my gut feeling was probably right. Though I still think it's suboptimal, that you need to tinker to change the whole windowing system just for Xemu, it does not sound to good to my ear ... :-/

When you posted this message above (full output from Xemu from start to exit) have you've tried to click meanwhile?

Yes, several right and left clicks in the window during the run shown.

Also I'm curious if you had any dialog box shown while having this problem

No dialogs by that time. The initial handful of dialogs do pop up during startup (the one about the SD card, initializing the working dir, etc.), but all of those dismiss correctly with a left click. There is nothing visible except the MEGA hypervisor screen (black with white text, in an infinite loop asking for ROM/SD card or whatever).

Though I still think it's suboptimal, that you need to tinker to change the whole windowing system just for Xemu, it does not sound to good to my ear ...

It's a minor annoyance, not a showstopper. Switching requires logging out and back in again, it isn't super painful. There is a selection switch in the settings on the login screen to choose Gnome/Classic Gnome/X11 Gnome. (With "Gnome" being Wayland and the default.)

As for the function keys, they behave badly in exactly the same way under X11, too, so there must be something else going weird there. I'll do some googling to see if I can find anybody else with the same issue.

But, the current state of things is that I'm able to boot a MEGA65 ROM and interact with the system and it seems to mostly be working (except function keys, maybe just some, maybe all, I dunno yet), so that's progress.

Apparently my keyboard is just weird. As with this issue (https://github.com/libsdl-org/SDL/issues/4023) I have a Keychron mechanical keyboard. Putting it into MacOS mode makes the function keys behave maybe right (I get @9$ for F3 which I guess is a magic thing to load from device 9, and F4 tries to load from tape, so that seems like probably a sensible thing for it to be doing...I don't actually know, this is my first experience with a MEGA65).

So, the only problem remaining is that something in the toolchain doesn't work with Wayland.

Just for curiosity, you may try the default Wayland setup and in a terminal window (beware, it's GDK not GTK here, different subsystems):

export GDK_BACKEND=x11

then starting the emulator (of course from the same terminal window, from command line). If it really works, then it's an interesting question if I can find out some automatic process so even this variable does not need to be set by the user, and "just work" also without requesting "classic x11" stuff, which is ugly.

I may try to detect the actual thing SDL uses, and force GTK (GDK to be precise as GTK's backend) to force the same. However I am a bit nervous that a workaround like this may break on systems then which do not need the workaround at all ;)

That does the trick!

Everything seems to be working under Wayland now. Thanks for your persistence!

I've just make an entry for issue #297 to have some solution for this, which does not need any user level interaction/trick/workaround.

Oh, and sorry I've forgot to answer:

Works if I run it under X11 instead of Wayland! Good catch.

So, I guess the "bug" is that maybe SDL isn't doing the right thing on Wayland? I think I've used some other SDL apps that act right, but I'm not super confident about that. I'll leave it up to you as to whether it's something you can address in xemu or if it needs to be kicked up the stack to SDL or Wayland or somewhere else.

I am not sure we can say, "SDL isn't doing the right thing in Wayland". Probably it's expected that SDL does not know Wayland (??) and uses X11 which is provided protocol even under Wayland for compatibility. The issue that GTK does know Wayland. So there is the odd situation that SDL does not use Wayland and use X11, while GTK detects Wayland and use it, but since Xemu uses both there is some interesting complication that mixing both protocols causes headaches .... So in essence both SDL and GTK is right. SDL can use x11 if it want, since it still works. GTK has the right to use Wayland (why not ...) if it's available. Neither of these behaviours are bad, but the mix of them within a single application can be ;) It's possible that SDL does not support Wayland, or just Fedora compiled SDL to support x11 only, or SDL has priority to use x11 if both of x11 and Wayland is available.

I think, it does not worth to prepare for all combinations (who knows other distributions compile which version of SDL with which default settings ...). it's maybe better for a "real" fix to detect what SDL uses as backend, and force then GTK to use the same. This is because SDL is initialized first, and that's the base of Xemu, GTK is only used for the UI (context-menu, open file dialogs, etc).

Thanks for the hint that got it working for me. For now, I'll just restart in X11 whenever I want to tinker with xemu. Might be worth adding a note for others who might run into this.

Indeed. However I am not sure, how typical this problem is. Eg I don't know why SDL uses x11. Or it's specific to your system, and lib version in that particular setup. But that's the reason, I've opened the more generic issue page #297 to solve this issue for other people without requiring extra effort from them. It's one thing that you seems to be OK to apply manual workarounds and you even understand what's going on, but not all users can do this, or we can say, not all users want to "mess with these" :)

Can you please try the dev branch? I've made a workaround there (before including in branch next or master) which may does the workaround job automatically without the need of any human interaction as per #297 ). In theory it should work now, with/without Wayland and without any workaround at all (well, internally it has a workaround, I mean, the user does not need to do anything ... if it works). I cannot test this unfortunately. So it would be very kind of you, if you can help in advance. Thanks a lot in advance.

I've reopened the issue, since I feel it deserve a proper fix that not-so-technical users can run it as well. It's one thing that it seems both of us are ok with workarounds and how to do it, but it's maybe not true for everyone ...

Can you please try the dev branch?

Yep. Seems to do the right thing. I'm able to start it without setting the env variable, and the debug log shows:

GTK: setting environment variable  GDK_BACKEND=x11 to avoid possible GTK backend mismatch with SDL

Confirmed I have a right-click menu, as well.

So, I think this can be considered worked around, if not fixed.

Thanks for testing! So then I consider this good enough for now, as the user won't notice and don't need to do anything, which would be the goal :)

lgblgblgb / xemu

GTK-UI: No menu on right-click on Fedora 34 #296