Support for cross-platform clipboard

[Wengier]

Right now clipboard support (copy, paste etc) is only supported in the Windows platform, and for Linux and macOS the feature is simply disabled. This is certainly not the ideal behaviour, and I have heard some Linux user would like to see clipboard support, so I hope there exists a light-weighted cross-platform library (similar to TinyFileDialogs used for dialog box) so that cross-platform clipboard support can be added for DOSBox-X, not just on Windows.

[joncampbell123]

Not sure yet about Mac OS X, but Linux/X11 support could be done at the Xlib X11 protocol level.

https://www.uninformativ.de/blog/postings/2017-04-02/0/POSTING-en.html

[joncampbell123]

Ah, I think this is Mac OS X's clipboard API.

https://developer.apple.com/documentation/appkit/nspasteboard

[Wengier]

@joncampbell123 Thanks. I will try the Linux/X11 code, but I think the Mac OS X's clipboard API is Objective C only (not C++). I hope to get it work at least in Linux, but it will be the best if there is a solution for all supported platforms of course.

[joncampbell123]

There are parts of DOSBox-X that are Objective C++. I've had no problem compiling .mm files as part of the project on Mac OS X. The NSMenu support code in ./src/gui/menu_osx.mm for example.

It's possible to write Objective C++ that regular C++ can interact with.

[Wengier]

@joncampbell123 I have tried the X11 code, which seems to be able to get X11's clipboard text properly. However, setting X11's clipboard text is more problematic, and I kept getting "Denying request of type xxx" with the code even if it builds fine. I have also tried to change the code somewhat, but I was not able to get this to work as desired, partly because I am not particularly familiar with the X11 protocol.

Meanwhile, I have also tried libclipboard (https://github.com/jtanx/libclipboard), a lightweight cross-platform clipboard library, which seems to work fine in Windows (both copy and paste), but the code seems to freeze with Linux/X11. I have checked there are multiple places in the code that can cause freezes in the X11 code, so I had to discard it for now.

[rderooy]

@Wengier just a thought... are you actually running X11 or are you running Wayland? I suspect the later. X11 has a sort of free-for-all model where any X11 app can access anything, while wayland introduces a security model. You may be running into the later, even though Xwayland (under which dosbox-x should be running) has a more relaxed security model.

To test if this is the case, at the graphical login screen when you select your user, there should be a little gear icon. Press this and select something like "Gnome on X11", and try again. Not that this is a solution obviously.

[Wengier]

@rderooy I simply used the preprocessor #if defined(LINUX) && C_X11 to check if it is Linux/X11 in the code. But as I primarily use Windows, you are certainly more familiar with Linux than me.

I wonder where I can find the little gear icon at the graphical login screen? I have not found it for now, so could you post a screenshot showing it? Thanks!

[rderooy]

@Wengier they changed the location of the icon at some point. I think you said you where running Fedora 31, which I think had it just underneath the Password input field, next to the sign in button. In Fedora 33, it is in the bottom right corner of the screen.

Once you find the gear icon, select "GNOME on Xorg".

Again, you will not see the gear icon if you have not yet selected the user to login as. Also you will not see it on the lock screen, you need to be at the login screen.

old location: https://tracker.pureos.net/file/data/ilr4x43gc4ctz6e67nny/PHID-FILE-uv33u5fu7v64hbttxl3u/GDM-screenshot.png

[rderooy]

Also note that the option is "sticky", so it will remember the option you last chose on subsequent logins.

[Wengier]

@rderooy Yes you are right, I can find "GNOME on Xorg" only at the login screen, but not the lock screen.

[Wengier]

@rderooy Nevertheless, the result I got when logged in as "GNOME on Xorg" seems to be the same as before. Instead of successfully setting the X11 clipboard with the code, I continue to get messages likes this:

Requestor: 0x2400002
Denying request of type 'TARGETS'

[Wengier]

Maybe the sample code itself has issues. If there is other code there may work with Linux clipboard please let me know as well. Also, I do not have macOS here so I am not able to test the macOS clipboard code myself.

[rderooy]

Not sure if this helps... Another emulator that uses SDL2 has recently implemented copy and paste functionality. openMSX, the emulator for an 80's home computer system popular in Japan and to some extend Europe.

Here is a commit where they implement paste functionality using SDL2. https://github.com/openMSX/openMSX/commit/9bdf1d2383e83b1858aa926e5fc70893d8d65a96

[Wengier]

@rderooy Thanks for the link. Yes, it will work! However this will make the Linux (and likely also macOS) clipboard feature SDL2 only.

[Wengier]

@rderooy The mouse copy/paste feature is now available for non-Windows systems on SDL2 builds, and pasting from the clipboard (via the key mapper) is also available for the Linux/X11 systems on SDL1 builds (https://github.com/joncampbell123/dosbox-x/commit/f4a58b12c8984e7959e92cfae926b061632d4f4a). On the other hand, the clipboard device (CLIP$) and DOS clipboard API are currently still Windows-only.

[rderooy]

@Wengier I know that the SDL2 feature would obviously preclude SDL1. But on the other hand, it should be cross-platform and work on Linux, Windows and macOS. And hopefully it is also compatible with Wayland, once the SDL lack-of-window-decoration-on-wayland issue is sorted upstream.

Generally, I think it would be a good idea to start to default to SDL2. And only promote the SDL1 builds for legacy platforms that cannot support SDL2. Are there any features left that are SDL1 only, after SDLNet got sorted?

[Wengier]

I agree with the general idea to make SDL2 the preferred build, but apparently @joncampbell123 knows more about the details of the differences between SDL1 and SDL2 builds. Perhaps there should be a Wiki page to explain the differences between them to let the end-users know how to choose between them.

[joncampbell123]

SDL2 builds use the stock SDL2 library code since that is an actively developed project.

SDL1 builds use a version that I have heavily modified since SDL1 is apparently deprecated. However my heavy modifications allow for many extensions to work, including Win32 language ID, menus, asynchronous window resizing (meaning that moving and resizing the window doesn't pause emulation), alterations for @yksoft1 for HX DOS builds, Apple touch bar support, etc. Those alterations cannot be done to SDL2 builds without modifying SDL2 heavily as well, which is a bad idea considering that fixes and upgrades may be obtained by just updating the SDL2 library from the main site.

[Wengier]

@joncampbell123 It is true that the SDL1 build has things that work differently in SDL2 build when you mention the extensions, most notably the menu system in Windows SDL1 builds. I think right now this one is still preferred over the menu system in Windows SDL2 builds, which use SDL custom drawn menu system. For example, when you use the GLSL shader in OpenGL output, the menu bar will disappear in Windows SDL2 builds, but not in Windows SDL1 builds, so it does have its apparent advantages. I hope to create a Wiki page shortly to explain to users about the differences between them and how to choose between them.

[Wengier]

@joncampbell123 By the way, speaking of the SDL drawn menu issue, if you know how to make the GLSL shaders work with the SDL drawn menu (Issue #1887), please let me know. Thanks!

[joncampbell123]

@Wengier I'm aware that SDL2 opens up the ability to use and allocate OpenGL contexts, so perhaps the menus should have their own OpenGL context separate from the DOS screen and it's shader. I'm not entirely sure if the two contexts could coexist on the same window though.

[joncampbell123]

https://wiki.libsdl.org/SDL_GL_CreateContext

[joncampbell123]

If they could, great. Otherwise, it's a potential mess of code much like how SDL1 has to delicately manage the OpenGL context when sharing it with 3Dfx emulation. It's so delicate that the window has to prevent you from resizing it while 3Dfx OpenGL emulation is active.

[Carpintonto]

Having an impasse here on Ubuntu 18.04.5.

I just got v0.83.7, Linux SDL2, 64-bit to compile this afternoon, but at runtime it complained: dosbox-x: error while loading shared libraries: libavcodec.so.58: cannot open shared object file: No such file or directory and the same for libavformat.so.58, libavutil.so.56, libswscale.so.5, libswresample.so.3, and libfdk-aac.so.2

Each time I located and copied the missing shared libraries in the snap installation until it ran sudo cp /snap/dosbox-x/597/usr/lib/libswresample.so.* /usr/lib/x86_64-linux-gnu

Now with whatever I cloned at around 11:30pm PDT

build-debug-sdl2 -rw-rw-r-- 1 john john 23 Oct 13 00:16 stamp-h1

I see a lot of //usr/lib/x86_64-linux-gnu/libavcodec.so.57: undefined reference to ...

I tried with and without the shared libraries I copied from the /snap/dosbox-x/597/usr/lib/ to /usr/lib/x86_64-linux-gnu

Attached find config.log and the end of the console output

config.log console_tail.txt

[Wengier]

@Carpintonto I think you seem to have issue with the avcodec. Perhaps you can try disable this feature if you do not really need it:

./configure --disable-avcodec

[Wengier]

@joncampbell123 Looks like it is kind of problematic to make the GLSL shaders work with the SDL drawn menu. So far I have not yet found references to make two OpenGL contexts coexist on the same window.

[Carpintonto]

@Wengier I think I understand you to mean run

./configure --disable-avcodec and then ./build-debug-sdl2

No discernible change - still throwing //usr/lib/x86_64-linux-gnu/libavcodec.so.57: undefined reference to ....

and interestingly, even when it does compile, grep error config.log | wc -l always returns 47.

My healthy boundary on this project is to NOT edit any code.

I'm glad to try suggestions, move files around, and report back so the team can get a sense of what's happening and not on Ubuntu 18.04.5. <-- for what it's worth; I'm getting the suggestions to upgrade the distro so my help may be of limited applicability until I do.

[Wengier]

@Carpintonto No, if you run ./build-debug-sdl2 after ./configure --disable-avcodec then the configure option will be overridden and has no effect. Try run ./configure --disable-avcodec and then “make” instead.

[Carpintonto]

@Wengier
no go - the console output suggest two OpenGL contexts will not work?

In file included from ../../src/output/output_opengl.h:7:0, from ../../include/sdlmain.h:199, from sdlmain_linux.cpp:10: /usr/include/SDL/SDL_opengl.h:116:0: warning: "GL_GLEXT_VERSION" redefined

define GL_GLEXT_VERSION 29

In file included from /usr/include/GL/gl.h:2050:0, from /usr/include/SDL/SDL_opengl.h:46, from ../../src/output/output_opengl.h:7, from ../../include/sdlmain.h:199, from sdlmain_linux.cpp:10: /usr/include/GL/glext.h:54:0: note: this is the location of the previous definition

define GL_GLEXT_VERSION 20190911

console_tail--disable-avcodec.txt

[Wengier]

@Carpintonto These are just warnings which you can ignore.

The actual error seems to be about the SDL1 (This code must be compiled using the SDL 1.x library provided in this source repository). Make sure you build for SDL2 instead of SDL1 since you want the SDL2 build.

./build-debug-sdl2 Stop after avcodec errors, then: ./configure --disable-avcodec make

[Carpintonto]

@Wengier still not happening. I really want to paste in from the clipboard to report success. I also do other things! Maybe you try qemu hosting Ubuntu?

[Wengier]

@rderooy is more familiar with Linux stuff than me (since I am a Windows user). He can probably help you in this case.

[Carpintonto]

@Wengier - I'm trying to help YOU. If I NEED to paste from a DOS emulator, I already can

Written by Stas Sergeev, FDPP project. Based on FreeDOS sources (C) Pasquale J. Villani and The FreeDOS Project.

This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

C: HD1, Pri[ 1], CHS= 0-1-1, start= 0 MB, size= 2000 MB D: HD2, Pri[ 1], CHS= 0-1-1, start= 0 MB, size= 2000 MB E: HD3, Pri[ 1], CHS= 0-1-1, start= 0 MB, size= 2000 MB F: HD4, Pri[ 1], CHS= 0-1-1, start= 0 MB, size= 2000 MB dosemu XMS 3.0 & UMB support enabled dosemu EMS driver rev 0.8 installed. EMUFS host file and print access available dosemu CDROM driver installed (V0.2) Kernel: allocated 115 Diskbuffers = 62560 Bytes in HMA Process 0 starting: F:\command.com /e:384 /k %FDPP_AUTOEXEC% BLASTER=A220 I5 D1 H5 P330 T6 MIDI=SYNTH:2 MAP:E MODE:0 Welcome to dosemu2! Build 2.0pre8-20201004-2355-gc2590dee5

C:>

[Wengier]

@Carpintonto Sure I would like to see DOSBox-X's clipboard working in Linux, and I appreciate any help for that. But if I understand it correctly, the issue you currently encounter is with the code building in Linux (Ubuntu), right? And the code that prevents it from building correctly on your system is clearly not the clipboard code, but something else (avcodec etc which has nothing to do the clipboard). Since @rderooy is more familiar with the Linux system in general, I hope he could help you to solve the Linux building issue you encountered (which is unrelated to the clipboard code). And after that we can start to discuss the actual clipboard function for Linux in DOSBox-X, and I certainly appreciate that. Thanks for your support.

[Carpintonto]

@Wengier I got v0.83.7, Linux SDL2, 64-bit to compile yesterday afternoon, but at runtime it complained: dosbox-x: error while loading shared libraries: libavcodec.so.58: cannot open shared object file: No such file or directory and the same for libavformat.so.58, libavutil.so.56, libswscale.so.5, libswresample.so.3, and libfdk-aac.so.2

Each time I located and copied the missing shared libraries in the snap installation until it ran sudo cp /snap/dosbox-x/597/usr/lib/libswresample.so.* /usr/lib/x86_64-linux-gnu

and it's running right now- I'll watch for a release.

[Wengier]

@Carpintonto So you meant you have already managed to get DOSBox-X SDL2 working in your Linux system? Great if this is the case. If DOSBox-X is already running right now, have you tried the mouse clipboard copy/paste feature already? For example, under "Main" menu there is a "Shared clipboard function" menu group; you can enable "Quick Edit" and then select, copy or paste text using the mouse button. Let me know if you find any issues with the feature. Thanks!

[Wengier]

@Carpintonto On the other hand, if you still encounter build issues on your Linux system with the latest code, it should be clear from the errors that they are not related to the clipboard feature, but may be caused by other feature or changes.

[rderooy]

@Carpintonto looking at https://packages.ubuntu.com/search?keywords=libavformat I notice something weird. You say your running 18.04. Yet libavcodec.so.58 is from ubuntu 20.04. That is why you don't find the libraries. The binary was compiled for a newer Ubuntu release. So either upgrade to Ubuntu 20.04, or compile it on Ubuntu 18.04 with the libraries and header files from that release.

[Wengier]

@Carpintonto I think it may be a coincidence, but the errors when you built with the newer code are indeed unrelated to the clipboard feature. There are multiple code improvements made in the past 24 hours (only some of them were made by me), and the build issue you may have encountered on your Linux system must be caused by something else.

[Carpintonto]

@rderooy thank you Robert - that's some enlightenment

@Wengier I refer you back to https://github.com/joncampbell123/dosbox-x/issues/1938#issuecomment-707561388

re-read what I said. That's the version still running. Whatever you have done since that commit has broken all efforts I've made since 11:30 pm last night on my 18.04.5

I am not going to upgrade my distro just to see IF I can compile the latest from a cross-development effort attempted on Windows.

Read this whole thread - seems like everybody's waiting to talk and nobody's listening- it's like Abbott and Costello's Who's on First.

It has been entertaining. Cheers!

[Wengier]

@Carpintonto Yes, I have already got what you meant - you meant that the code before last night did build but showing missing shared libraries, which can be solved after some efforts. On the other hand, the code after 11:30 pm last night does not build due to the avcodec errors etc. This is correct, right?

HOWEVER, as I have already mentioned in https://github.com/joncampbell123/dosbox-x/issues/1938#issuecomment-707962702 the errors with the newer code are indeed unrelated to the clipboard feature. I have also mentioned in that comment that I was not the only one who has made commit since that time, and in fact I did not change anything related the avcodec feature recently (actually never). I do not know who has modified the code related to the avcodec feature recently, but it should be clear it was not me.

[Carpintonto]

nor I !

[Wengier]

The most important thing is not to find out who modified the code I think, but to fix it when a problem is found. Thanks for reporting this so that we can try to check the problem.

[Wengier]

@rderooy Could you please check what may be wrong with the recent code (related to avcodec) that may cause the issue that @Carpintonto encountered? You are surely a Linux expert.

[rderooy]

@Wengier I will try to find a moment tomorrow.

[rderooy]

A few things. DOSBox-X as mentioned uses a custom SDL1 build. I found that sometimes with a clean tree, in particular with the flatpak build, I first needed to build SDL1. As such give this a try for SDL1:

cd vs2015/sdl
./build-dosbox.sh
cd ../..
./build-debug --disable-avcodec

Regarding avcodec. with ldd you can check against which external libs a binary is linked.

Here is a SDL1 build result, looking for AV

$ ldd dosbox-x |grep -i av
    libavcodec.so.58 => /lib64/libavcodec.so.58 (0x00007f7924661000)
    libavformat.so.58 => /lib64/libavformat.so.58 (0x00007f7924412000)
    libavutil.so.56 => /lib64/libavutil.so.56 (0x00007f792416e000)
    libdav1d.so.4 => /lib64/libdav1d.so.4 (0x00007f7923393000)
    librav1e.so.0 => /lib64/librav1e.so.0 (0x00007f7921fd4000)

As you can see, it is linked against avcodec.

Here is another SDL1 build, this time compiled with --disable-avcodec:

$ ldd dosbox-x|grep -i av

As you can see, it returns nothing. So it is NOT linked against avcodec.

I also tried the same thing with SDL2, and the same thing applies when checking with ldd.

Note: running --disable-avcodec against ./configure is pointless if afterwards you run a script like build-debug, since the build scripts will just run configure again, which will re-enable it. So you want to just skip running configure and just directly run the build script, but with the -disable-avcodec parameter as I show above.

[Wengier]

@rderooy So you think the avcodec feature in DOSBox-X always behaves like this, i.e. there is no regression in the recent code that may cause building issue with avcodec in Linux?

[rderooy]

@Wengier I would not say there are no regressions. As you may recall I had created a bug report that win9x crashes on startup after enabling avcodec (that got subsequently overrun by someone posting unrelated issues), and that I just closed. Those crashes still happen. But they are not related to any change to the code itself, but simply to the config system. With the old detection method avcodec simply did not get enabled on my system as it never found the libraries, with the new one it does find the libs and enables it and crashes on starting windows.

[Wengier]

@rderooy It looks like @Carpintonto is unable to build the latest code successfully in Linux due to the avcodec stuff. Do you have for example a Linux Flatpak build for the latest code that can be used to demonstrate the Linux clipboard feature to @Carpintonto?

[rderooy]

@Wengier There is no point in me providing a binary, since it will have the same problem as the snap version he seems to be using now. Namely that it is compiled against newer libs.

For the flatpak, the flathub repository is only for tagged release versions. Which means waiting another 2 weeks.

It is possible for nightly flatpaks to be hosted on your own webserver. Perhaps this could be done on dosbox-x.com There is some docs for hosting your own repository here: https://docs.flatpak.org/en/latest/hosting-a-repository.html But I have not tried this, but I think you can just run the build-flatpak-sdl2.sh script and put the resulting "myrepo" repository directory that is created onto the web server. Perhaps just rename "myrepo" to something else in the build script :-)