Прошу помощи в реализации Wayland протокола в RetroArch

У меня вопрос. А зачем им вообще отдельная поддержка Wayland и прочих протоколов, если у них имеется SDL2-backend?

https://github.com/libretro/RetroArch/blob/master/gfx/drivers/sdl2_gfx.c

Насколько я понимаю, именно этот Backend и задействован по-умолчанию на Linux? Или нет?

Если да, то тогда уж лучше отвязать вот это от иксов, добавить туда Wayland:

https://github.com/libretro/RetroArch/blob/master/gfx/drivers/sdl2_gfx.c#L214

И тогда этот RetroArch будет без проблем работать в нативном Wayland'е через:

$ SDL_VIDEODIREVER=wayland RetroArch

А что там будет xdg-shell или wl_shell, это уже будет решать SDL2, на его плечах будет лежать забота по поддержке тех или иных протоколов. Разве это не правильный путь?

У меня вопрос. А зачем им вообще отдельная поддержка Wayland и прочих протоколов, если у них имеется SDL2-backend?

По умолчанию в Linux задействован драйвер gl (OpenGL), а при запуске выбирается контекст в соответствии с окружением (X11, Wayland, и тд). То есть если реализовать всё через SDL, то поддержка Wayland будет только в нём. А так она есть во всех поддерживаемых драйверах вывода. Если я правильно понял.

а при запуске выбирается контекст в соответствии с окружением (X11, Wayland, и тд).

Похоже даже так: при запуске на Linux в любом случае проверяется возможность подключения к wayland-server'у, если невозможно подключиться — откатываетмся на X.Org + GLX.

То есть если реализовать всё через SDL, то поддержка Wayland будет только в нём. А так она есть во всех поддерживаемых драйверах вывода. Если я правильно понял.

Да, я думал под Linux этот RetroArch является чисто SDL2-приложением, но там всё довольно сложно. И, например, из этого RetorArch можно вызывать дополнительное GUI на Qt (опция Show Desktop Menu), при этом, если не будет выставлено QT_QPA_PLATFORM=wayland, то оболочка на Qt запустится через XWayland, а не Wayland.

И конечно же на Fedora 29 и GNOME 3.30.2 у Wayland-окна этого RetroArch нет заголовка. Когда они наконец разупорятся...

Кстати, у тебя этот драйвер SDL2 для вывода видео вообще работает? У меня чёрный экран и в нижнем левом углу жёлтая каша из пунктов меню. Я так понимаю, он тупо сломан в апстриме?

P.S. с твоим патчем, кстати, что-то не собирается:

LD retroarch
/usr/bin/ld: obj-unix/release/gfx/drivers_context/wayland_ctx.o:(.data.rel.ro.local+0x0): multiple definition of `gfx_ctx_wayland'; obj-unix/release/gfx/drivers_context/wayland_ctx.o:(.data.rel.ro.local+0x0): first defined here
/usr/bin/ld: obj-unix/release/input/drivers/wayland_input.o: in function `input_wl_init':
wayland_input.c:(.text+0x6e0): multiple definition of `input_wl_init'; obj-unix/release/input/drivers/wayland_input.o:wayland_input.c:(.text+0x6e0): first defined here
/usr/bin/ld: obj-unix/release/input/drivers/wayland_input.o:(.data.rel.local+0x0): multiple definition of `input_wayland'; obj-unix/release/input/drivers/wayland_input.o:(.data.rel.local+0x0): first defined here
/usr/bin/ld: obj-unix/release/deps/lua/src/loslib.o: in function `os_tmpname':
loslib.c:(.text+0x2a0): warning: the use of `tmpnam' is dangerous, better use `mkstemp'
/usr/bin/ld: obj-unix/release/input/drivers/wayland_input.o: in function `input_wl_poll':
wayland_input.c:(.text+0xc9): undefined reference to `flush_wayland_fd'
/usr/bin/ld: wayland_input.c:(.text+0x13d): undefined reference to `wayland_context_gettouchpos'
/usr/bin/ld: obj-unix/release/input/drivers/wayland_input.o: in function `input_wl_poll':
wayland_input.c:(.text+0xc9): undefined reference to `flush_wayland_fd'
/usr/bin/ld: wayland_input.c:(.text+0x13d): undefined reference to `wayland_context_gettouchpos'
collect2: error: ld returned 1 exit status

Глубже пока не смотрел.

Глубже пока не смотрел.

Кажется, вот этот патч сломал сборку:

https://github.com/libretro/RetroArch/pull/7607/files#diff-1c2b8e7c48acf6b442...

Ты конкатенируешь к OBJ объектники wayland_ctx.o и wayland_input.o, которые ещё раз добавляются немного ниже. Возможно, тут ты хотел сделать что-то вроде:

 ifeq ($(HAVE_WAYLAND), 1)
    OBJ += gfx/drivers_context/wayland_ctx.o \
-          input/drivers/wayland_input.o
+          input/drivers/wayland_input.o \
+          gfx/common/wayland/xdg-shell.o
    ifeq ($(HAVE_EGL), 1)
       LIBS += $(EGL_LIBS)
    endif
    DEFINES += $(WAYLAND_CFLAGS) $(WAYLAND_CURSOR_CFLAGS)
    LIBS += $(WAYLAND_LIBS) $(WAYLAND_CURSOR_LIBS)

Но почему-то получилось то, что у тебя там в PR.

И ещё некоторые советы по предстоящей работе в Git/GitHub. Возможно будут полезны.

1.

$ git log --format=fuller --graph
* commit c32c98e667e352bd8f44dcab496050339d4af043 (HEAD -> test)
| Author:     Sunderland93 <sunderland93@Debian-Gnome>
| AuthorDate: Sat Nov 17 16:01:51 2018 +0400
| Commit:     Sunderland93 <sunderland93@Debian-Gnome>
| CommitDate: Sat Nov 17 16:01:51 2018 +0400
| 
|     Very WIP: xdg-shell support
|   

Вот это <sunderland93@Debian-Gnome> не является нормальным ящиком. Из-за этого на GitHub'е твой коммит выглядит с двумя именами аля Sunderland93 authored and Sunderland93 committed.

Задай себе нормальный ящик в .gitconfig, который совпадает с тем, что используется у тебя на GitHub'е. Так будет понятно, что коммиты идут именно с твоего профиля, а заинтересованные в изменениях смогут с тобой связаться.

2.
Ты зачем-то закрыл свой прошлый PR (там у некоторых коммитов кстати как раз был нормальный ящик), и создал новый. Это делать совсем было не обязательно. Вот, например, ты захотел исправить ту ошибку сборки с двойным добавлением одинаковых объектников, которую я указал выше. Ты можешь пойти следующими путями:

2.1. Сделать изменения в файле, исправляющие ошибку сборки, затем сделать что-то вроде:

$ git add .
$ git commit -m "Fix build error"
$ git push origin master

Эти действия добавят ещё один коммит к твоему PR на GitHub'е.

2.2. Сделать изменения в файле, исправляющие ошибку сборки, затем сделать:

$ git add .
$ git commit --amend
$ git push -f origin master

Эти действия перезапишут старый коммит в твоём PR на новый с исправленной ошибкой сборки. ИМХО это самый верный вариант, который позволяет избежать кучи коммитов и сохранить атомарность изменений. Именно подобным вкупе с git rebase -i и нужно было воспользоваться ранее, а не закрывать старый PR, создав новый.

у Wayland-окна этого RetroArch нет заголовка. Когда они наконец разупорятся...

Гномовцы хотят чтобы все софтописатели пилили CSD, и никак иначе https://gitlab.gnome.org/GNOME/mutter/issues/217

К слову у RetroArch в текущем виде и так рамка не рисуется. Это моя следующая хотелка - запилить поддержку расширения xdg-decoration, благо там несколько строк кода всего. Но без xdg_shell работать не будет. Кдешники обещают поддержку в Plasma 5.15, в SDL тоже добавят (сейчас добавили Кдешную реализацию серверных декораций), в Mir добавят. Короче народ старается в стандарты, а Гномовцы стоят на своём.

Благодарю, оставлю себе как заметку

Сейчас гляну

Как я понял, получение GL-контекста ты ещё не реализовывал?

А то у меня при запуске сегфолт на разрешении адресов GL-функций из-за того, что GL context — NULL.

$ ./retroarch -v
...
[INFO] [Video]: Video @ 960x720
[INFO] [Wayland]: Physical width: 340 mm x 190 mm.
[INFO] [Wayland]: Video mode: 1366 x 768 @ 60.0140 Hz.
[INFO] [Wayland]: Setting buffer scale factor to 1.
[INFO] [Wayland]: Seat name: seat0.
[INFO] [EGL] Found EGL client version >= 1.5, trying eglGetPlatformDisplay
[INFO] [EGL]: EGL version: 1.4
[INFO] [Wayland]: Loaded keymap.
[INFO] [GL]: Found GL context: wayland
[INFO] [GL]: Detecting screen resolution 1366x768.

vs.

$ ./retroarch -v
...
[INFO] [Video]: Video @ 960x720
[INFO] [Wayland]: Seat name: seat0.
[INFO] [EGL] Found EGL client version >= 1.5, trying eglGetPlatformDisplay
[INFO] [EGL]: EGL version: 1.4
[INFO] [Wayland]: Loaded keymap.
[INFO] [GL]: Found GL context: (null)
[INFO] [GL]: Detecting screen resolution 32766x1.
Segmentation fault (core dumped)

А потом в софте дыры находят, ага.

как и в твоей мамке

как и в твоей мамке

Пажжи, у твоей мамки нет дырок? Ни одной? Может ты приемный?

я синтезированный

Гномовцы хотят чтобы все софтописатели пилили CSD, и никак иначе https://gitlab.gnome.org/GNOME/mutter/issues/217

Гномовцы пусть своё видение засунут куда подальше. CSD для SDL было бы тем ещё извращением.

Не то что бы не реализовал...я его сломал. И пытаюсь починить

Если не сложно - глянь варнинги, может в них ещё проблема

Ok, хотелка успешно реализована! И не одна https://github.com/libretro/RetroArch/commit/b538786b00a1a820e156646a87baa969... Осталось решить пару мелких недочётов и запилить серверные декорации окон. Безумно горжусь своим скромненьким вкладом в закапывание иксов!