[WIP] Add prototypical SDL support. #403
Conversation
Build with cmake. This will create a new backend (ldesdl). - Resolution can only be set by editing the variables in sdl.c. - Key repeat does not work. - Still problems with keysyms that implicitly contain modifiers. - The entire screen is bitblted onto the SDL display every frame. Support keyboard, and work on mouse. Kind of working... Fix display resolution problems.
|
Open points:
|
|
UPDATE: new commit added, which is a bit faster at bitblting, and also supports pixel scaling (doubling, trippling, etc.) |
|
Is key repeating done in Lisp? On the D-machines it must have been... |
|
@nbriggs I think with the last push it should now only update the damaged parts. I didn't look into expose events in SDL yet, not sure how well those are supported. |
|
I can try on MacOS, assuming I can install/compile SDL without having to use "brew" (or anything like it). I don't have a Windows box. |
That would be great! Please take care to use SDL2, not any of the older versions ;) |
|
After installing the macOS SDL development framework... While they provide a development setup with a Framework to install, they forgot to include any cmake configuration stuff in there, so it'll take a while to sort that out. |
|
The CMake vs SDL answer is: While the SDL (version 2) disk image installs it as SDL2.framework, the CMake application for macOS, which is distributed with a .cmake file for SDL, believes that it is always called "SDL" not "SDL2" but is happy to locate that and tell you it's version 2. So... I renamed everything to just plain SDL and it configured fine. and and the actual fatal one: But after I fixed that, and a few more similar, something still knows that it used to call itself SDL2. Perhaps I can take the opposite approach, which is to copy /Applications/CMake.app/Contents/share/cmake-3.19/Modules/FindSDL.cmake to FindSDL2.cmake and fix up bits there to reflect the SDL2 name where appropriate. I'll also check and see if cmake-3.22 (RC1) has updated anything to do with SDL(2). |
|
smilar problems in Windows |
|
I haven't got all the kinks out of the SDL2.cmake (copied/modified from the CMake distributed SDL.cmake) but I got it far enough that lde and ldesdl link and run Even with the selective update, the sdl_bitblt_to_screen() is way way too slow. |
|
The includes in sdl.c for SDL files should be just |
|
Hello!
Thanks for playing around with this! So in theory at least this works
"natively" in MacOS, with no need to run any sort of X server?
I haven't got all the kinks out of the SDL2.cmake (copied/modified from the CMake distributed SDL.cmake) but I got it far enough that lde and ldesdl link and run
Even with the selective update, the sdl_bitblt_to_screen() is way way too slow.
Try doing "FB *.*;*" or bringing up a TEdit window on a moderate size file.
The Maiko "color" code isn't the answer -- that's for a separate color window which isn't the main screen.
Basically, the display code needs to do 1-bpp bitblt screamingly fast, which seems to be where XPutImage has an advantage over SDL.
I've changed things to only do the bitblt once on each "frame", it now
"feels" as fast as the X version on my machine (though at some point I
should add some profiling, to find out exact numbers).
The includes in sdl.c for SDL files should be just `"SDL.h"` and
`"SDL_keycode.h"` -- the `SDL/` is deprecated (according to the CMake
people) because FreeBSD doesn't put these includes in an SDL
subdirectory.
Thanks, changed it and pushed.
If it isn't too much trouble, could you pull in my changes and see
whether they work better?
Thanks for the help!
Greetings, Peter
|
|
Yeah, I've been following along. It works much better now. |
|
Yeah, I've been following along. It works much better now. `FB
*.*;*` in the Lispusers directory is a good test for how it's doing on
single character BLTCHAR, and that seems to be acceptably fast now.
Playing around with cygwin, not much success so far ;)
So, do you think this SDL thing is something worse pursuing further?
Should I clean up the code, to maybe start on an actual real Merge
Request?
Thanks for the help!
Greetings, Peter
|
|
If we can sort out the input (and things such as doing the 3-button mouse emulation) it's probably worthwhile pursuing. |
|
If we can sort out the input (and things such as doing the 3-button
mouse emulation) it's probably worthwhile pursuing.
When I do a bunch of FB redisplays, over a period of 35s runtime, the
`sdl_bitblt_to_screen()` is responsible for 36% of the execution time
-- so it's still more than it should be. Under X11,
`clipping_Xbitblt()` which is the equivalent, is too small to show up.
If we can't fix it any other way, I can probably write a shader that
works directly off the 1-bit bitmap, but as far as I know, that isn't
portable (at least not to Metal on MacOS).
I've been playing around with cygwin, there are some places where #ifdef
XWINDOW are missing, but I've gotten it to compile. However, SDL then
doesn't find any available video adapter.. I actually have no idea how
to properly compile stuff for windows, I'll try to find out more about
this :-/
Thanks for the help!
Peter
|
|
OK, finally got an mxe setup working for cross-compiling. From what it looks like, this codebase has never been compiled on anything like windows before, right? So we would need to add all those |
|
No The last time it was compiled on a Windows-like system it wasn't Windows, it was MSDOS, so there would be a lot of stuff to adjust, and there are things that will likely be I forgot to mention the |
|
I think I already added and pushed that, ran across that too.. so, what's the best way to proceed here? I'm no windows programmer, but I can try to fix things up. |
|
I think a Windows change set is orthogonal to SDL, though enabled by it. I think I need to make more changes in the FindSDL2.cmake. I believe all the variables it creates have to be SDL2_... instead of SDL_... Yes, we should talk about it on Monday. I'll continue to poke at getting things working properly on the mac between now and then, though. |
|
Sorry, it's the
|
|
These two changes broke compilation on macOS and FreeBSD -- |
|
|
BTW -- on FreeBSD, with default SDL2 install, it relies on the X11 back end, compiles/links without error, but generates if you try to run it when ssh'd into the box with X11 forwarding back to an XQuartz mac. |
It looks like it is trying to open an OpenGL context, and I'm not sure how well that would work over the network :-/ This is probably something that SDL cannot support. |
|
ok, fixed the build on ubuntu. still trying to understand how that SDL2::SDL2 stuff in cmake works exactly, so that we can make it work on macos and ubuntu and other linuxen. might be related to old versions of libsdl2 not shipping all the correct cmake files :-/ |
|
Well all the references to X11 libraries are X11::X11 so with no understanding of what it's really doing I'm not surprised that the SDL2 libraries are SDL2::SDL2 |
|
In all of these (CMake driven) builds it needs to do both X11 and SDL |
|
@nbriggs I've tried it, but the code (strangely) only displays entirely black... still investigating what's wrong here, I think it's related to the RGB332 pixelformat.. |
|
@ecraven -- I'll look at the FB speed, I suspect it's mostly in enumerating the files (again) when its reshaping, and it handles it differently the first time around. I compiled on FreeBSD 13.0, and over an SSH connection it used X back to my mac, with a correct display, but too slow to do much. You'll have noticed that I used the same pixel format that you did. I'll tidy up the allocation of the intermediate display buffer so that it's easier to change the pixel size and still get the buffer the right size. |
|
@ecraven -- While looking at the buffer related things I also looked at what textures the renderer supports (on a mac), and it says it's an "opengl" renderer, with support for textures so I guess choosing one of those would result in less conversion overhead? I'm setting up a version which picks up the first format returned and then asks for the black & white pixel values for that format, and the width of a pixel (in that format) in order to create the intermediate buffer. That way it should adapt a little to the underlying machine. |
|
@ecraven -- Was there a reason not to do SDL_TextureLock()..SDL_TextureUnlock() and update from the Lisp screen bitmap directly into the texture pixels? This avoids having any intermediate buffer, as far as I can see. You have to get the locking region exactly correct because anything that is locked MUST be updated. |
|
@nbriggs just my lack of knowledge ;D thanks for working on this! |
|
The SDL documentation does not give the clearest examples... I ran across the LockTexture stuff by accident as I was looking for something else, and it suggested that if you were using streaming textures you should lock and update the texture pixels directly. I'll push a new version, possibly as a separate branch, as soon as I've got something that gets the displayed bitmap correct, even if it's not the cleanest! |
|
@ecraven -- I've pushed a branch named sdl-texture-direct, started from the current sdl branch. With these changes, at least on my Mac, an idling Medley which is just flashing the cursor takes very little CPU time (also has background-yield loaded, though). Compile it after configuring with |
|
Things to think about: |
|
@ecraven -- Looking at the frame-rate: the |
|
How about this for situations where we have both SDL and X11 available -- in ldeboot.c if both SDL and XWINDOW are defined accept the "-d"/"-display"/DISPLAY environment variable, and if it's "SDL|sdl" then try to start ldesdl, otherwise pull out the display name and check it as it currently does and if the X connection succeeds start ldex. If only one is defined there's no choice, just do it. |
Nowadays there exist at least two alternative X environment variables, Note that other backends besides X and SDL will probably be added some years down the line. |
this would preclude using |
|
Good point. Or alternative names:
|
|
If we're considering changing the structure of lde, ldex, command line invoaction etc. in order to account for a new backend, now that there's a PoC for this, let's take a moment to consider the context. The scripts around run-medley and lde and etc. were all pretty ad hoc. I thought I heard there was some possibility of having just one executable instead of two. And changing the name from "lde" to "medley", I think. And doing a better job of invoking pixel scaling ... And... |
This makes it a bit more difficult to have a setuid root executable that can open the network device and then drop privs and fork the rest of the emulator. People would be rightly suspicious of depending on a larger piece of code that may or may not correctly drop (and not attempt to regain) root privs. However, if we think that it's possible on all the systems we care about to assign network access capability to either the user or the program, without giving root access, it's certainly worth considering. There's also the possibility of getting rid of the initial fork/exec and pipe communication for the external processes -- |
|
Updated the sdl-texture-direct branch with some cursor cleanups. |
|
@nbriggs cygwin` isn't important if we have Windows/SDL. Whether Windows implements copy-on-write isn't clear. (Interlilsp-10 on Tenex had copy-on-write). https://news.ycombinator.com/item?id=19621973 |
Setuid is perhaps the biggest anti-pattern in Unix programming - it should only be used for a handful of system programs like If the ethernet device needs to be opened, it would probably be best for the sysadmin to create a group for users who need access to the device, then If that doesn't work, there should be a minimally small daemon program that runs as root (but is not setuid) and gives other programs access to the device. |
That's the second choice if your system lacks a security capability architecture such as Solaris' role-based access control. If you install Wireshark on a Mac, using libpcap, it does the group setup etc. for you -- installing Related stuff: We've used the DLPI and NIT interfaces in the past, but if we're going to do raw ethernet access now then libpcap/BPF is probably the way to go. I think that BPF is now available on all systems where DLPI/NIT are (or were), so we can simplify the code. |
|
Neat! You know much more than I do about this stuff. libpcap is indeed popular nowadays. Whatever Wireshark does is probably a reasonable starting point. |
|
Updated the sdl-texture-direct branch with the code to fully deal with cursors in pixel-scaled presentation. |
|
I do mostly desktop Windows, and the amount of tacit knowledge there is about Maiko and Medley melts my brain. I am interested in graphic systems for gaming and took a deeper look at SDL2 because of this conversation. I have run into much chatter about raylib/SDL2/OpenGL/Vulkan and have been sticking with raylib for my own education at this point. My way ahead is by reverse-engineering sources (and CMakes) down to where I can do it all with command-line builds, getting the individual modules to compile, and then attempt integrated builds of .exe files. (I am looking to see how I can understand maiko that way, using procedures I am using elsewhere anyhow.) With regard to SDL2, this is what put me off.
I don't believe that statement. The README for Windows is out of date and also peculiar concerning Visual Studio version dependencies. I followed an #include chain looking for where things like I appreciate that configuring for different platforms is tricky. I was never very happy about how that worked when Unix flavors were the platform everywhere that EBCDIC wasn't. It's more difficult now, and having code uncluttered by the platform dependencies everywhere is seriously tricky. I don't have an answer. I just want to complain and prey that |
|
bump will recent changes to maiko make this harder or easier to complete? |
|
It means there is a lot of editing to do. We were waiting for the SDL people to fix an integration with CMake issue, they may have got around to releasing that, I haven't checked recently as they were moving very slowly. Re: dodo changes -- not sure, I haven't read the code. |
|
The Nethub extension to Maiko does not need any root/setuid/setgid priviledges: connecting to the Dodo Nethub uses plain TCP/IP client system calls. The purpose of the Nethub is to avoid any special APIs or executable rights if possible. The only exception may be the NethubGateway which is a Nethub-client connecting to a PCap device, allowing client machines (real or emulations) to connect to Dodo XNS services (see Dodo - Topology), this one may need root rights to use the PCap device (at least on Linux). BTW: some months ago i stumbled over the Nano-X Window System, which allows programs using one out of several UI-APIs to have their UI running on many other platforms (i did'nt have time to play with it yet, so no idea if it really works or which requirements must really be fulfilled) |
|
I have successfully rebased the interlisp/maiko SDL branch onto the most recent master and rebuilt with current SDL2 (2.24.2) on the Mac. Required a fix to the SDL2 installation because the installed framework include files refer to an SDL2 subdirectory ( |
|
I wanted to try this on Windows, but I was left pretty confused about which SDL configuration to try. |
|
Maiko depends on POSIX system calls for things as well as needing to talk to the keyboard/mouse/display.
|
I don't understand enough about connecting the dots. I do wonder if using the Windows Subsystem for Linux (WSL) would give you a more direct level of POSIX substrate. SDL should work in that case. A farther reach: The Standard C libraries are supported for native Windows builds. That may not be enough of POSIX and there is the question about SDL atop it, including how display loops and whatnot are accomplished at that level. I suspect there might be a show-stopper or simply too much work. I didn't check to know what the dependencies on Windows APIs might be presumed by the SDL distributions for Windows. |
|
@orcmid -- Maiko does work on WSL with no problem. Larry would like to have an option to be more Windows-native, for reasons I don't understand except for reducing friction for people to run it on Windows without the overhead of installing WSL and (potentially) an X server. SDL was promoted as a way to avoid having to have X and to have native display windows on many systems, and it does that, but that's not the only thing that needs to be solved to get to that state. It's entirely possible that Windows has got close enough to source compatibility with the simple POSIX functionality Maiko needs that it would be trivial to compile for it, if we can drive the compilation using either "make" or "CMake" -- neither setting up VSCode projects for Windows, nor XCode projects for the Mac seem like good investments of time. |
This is just a Merge Request to discuss, it is not ready to be merged in any way.
UPDATE: read along, all of the following is not true any longer ;)
Build with cmake. This will create a new backend (ldesdl).
init_SDLcall in main.c)