Previous 2.6 on Debian - Black window

Started by wizard, September 16, 2022, 02:46:06 AM

Previous topic - Next topic

andreas_g

#15
Does the black screen issue also occur on latest branch_softfloat? For the other problem I can't tell what might be wrong. If you have some skills with C and debugging maybe you can find the problem? There are debugging messages in the code that can be enabled individually.

ramalhais

Quote from: andreas_g on November 17, 2022, 02:11:09 AMDoes the black screen issue also occur on latest branch_softfloat? For the other problem I can't tell what might be wrong. If you have some skills with C and debugging maybe you can find the problem? There are debugging messages in the code that can be enabled individually.

I did a few tests with branch_softfloat, and when i start normally with ./previous, it seems to be using wayland, window is created but not displayed (shows in  alt+tab but you can't switch to it) and fails to use PulseAudio:

...
[SCC] Reset channel A
[SCC] Reset channel B
[KMS] Reset
[Sound] Initializing output device.
[Audio] Can't use audio: Could not connect PulseAudio stream
HANGS HERE ^

if i press ctrl+c, i can then switch to the Previous window, and it shows the message to quit. Then i can use it normally.

By running:
env - DISPLAY=:0 ./Previous
it looks like it's using X11 and i can use it normally, but the audio driver being used is ALSA which is different from above.

It might be some issue where audio is being initialized before the window, and hanging on pulseaudio failing.
Not sure why a different audio library is being used depending on wayland or X11.

wizard

Quote from: ramalhais on November 17, 2022, 11:39:27 AMBy running:
env - DISPLAY=:0 ./Previous
it looks like it's using X11 and i can use it normally,


Trying that I still get a black screen on my machine with NVIDIA drivers (Debian 11)
$DISPLAY=:0 environment variable is set anyway on my machine.

ramalhais

Quote from: wizard on November 17, 2022, 06:03:42 PMTrying that I still get a black screen on my machine with NVIDIA drivers (Debian 11)
$DISPLAY=:0 environment variable is set anyway on my machine.

The trick with that command is that it unsets all variables so that it won't use wayland, and then sets DISPLAY so that it uses X11/Xwayland.
have you tried pressing ctrl+c on the terminal where you launch Previous?

BTW, can you try branch_filesharing? That's the one that works best for me. I have built that both on ubuntu and fedora.

wizard

Quote from: ramalhais on November 21, 2022, 03:44:54 PMThe trick with that command is that it unsets all variables so that it won't use wayland, and then sets DISPLAY so that it uses X11/Xwayland.
have you tried pressing ctrl+c on the terminal where you launch Previous?

BTW, can you try branch_filesharing? That's the one that works best for me. I have built that both on ubuntu and fedora.

Ctrl-C will advance the emulator, but it is a black screen. Just tried with branch_filesharing
using  env - DISPLAY=:0 ./Previous

THe developer had sent me some fixes , so hopefully those will show up as those builds work for me.



andreas_g

I think it is time for a little clarification:
I am a hobbyist working on Previous for fun. I gladly share my work with the community in here and hope it is useful for some people. Anyway I do not have the capacity to provide extensive support for Previous. I do not earn any money with it and my time resources are limited. There are already thousands of working hours in this project.

Previous is developed and tested on macOS. So running Previous on macOS will provide the best experience and least bugs. Thanks to the help of many forum members Previous also runs on other platforms but due to the diversity of these platforms problems might occur on some systems. If I find the time I can help with debugging but the main work has to be done by the one experiencing the problem. If someome provides me with patches that fix specific problems, I'll apply them to the sources.

andreas_g

There is some new code in branch_softfloat (r1231) that is worth testing.

cuby

Quote from: andreas_g on November 25, 2022, 01:46:36 AMThere is some new code in branch_softfloat (r1231) that is worth testing.

Compiling works well except for the following:
  • The header file history.h (included from src/debug/debugdsp.c) is missing (removing the include seems to solve this)
  • libSDL2-2.26 or later is required to call SDL_GetWindowSizeInPixels in src/fast_screen.c (available in the latest Macports version)

However, I just noticed that the mouse is captured, but the mouse cursor does not move (in NeXTstep 3.3 as well as my bare metal test code https://github.com/michaelengel/Baremetal-NeXT). Previous thinks the mouse is captured and I can successfully uncapture it, but there's no reaction to mouse pointer movement. This is on Monterey 12.6.1/M1 Pro.


cuby

I think I found the problem. If fExp is == 1.0 in Main_HandleMouseMotion (main.c), then fDeltaX and fDeltaY are not being initialized. The attached diff fixes the problem for me.
previous_softfloat_r1231.diff.txt

andreas_g

#24
Quote from: cuby on November 29, 2022, 03:41:14 PMI think I found the problem. If fExp is == 1.0 in Main_HandleMouseMotion (main.c), then fDeltaX and fDeltaY are not being initialized. The attached diff fixes the problem for me.
previous_softfloat_r1231.diff.txt
Thank you very much for debugging this! Obviously a stupid mistake by me. I'll add your patch later today.

Update: Patch is online (with some extensions).

Do you see it as a problem, that Previous requires the latest version of SDL2? Personally I always upgrade to the latest version immediately. It almost always has more bug fixes than regressions.

nuss

Quote from: andreas_g on November 29, 2022, 10:09:13 PMDo you see it as a problem, that Previous requires the latest version of SDL2? Personally I always upgrade to the latest version immediately. It almost always has more bug fixes than regressions.

On Debian this means that we have to compile and maintain SDL2 by ourselves, as the system versions are not very recent. For me this is fine, as I use my own compiled versions for Previous more or less from the beginning. But it might be some blocker for people who want to compile Previous on a vanilla Debian system and do not know how to provide newer lib.

BTW: thanks for the fix @cuby :)
DON'T PANIC

ramalhais

Quote from: andreas_g on November 29, 2022, 10:09:13 PMThank you very much for debugging this! Obviously a stupid mistake by me. I'll add your patch later today.

Update: Patch is online (with some extensions).

Do you see it as a problem, that Previous requires the latest version of SDL2? Personally I always upgrade to the latest version immediately. It almost always has more bug fixes than regressions.

I think it would be nicer to have it compile or run with more common versions available in the latest distributions.
Maybe #ifdef the old/new code with SDL_VERSION_ATLEAST(X, Y, Z) (easiest way) or use SDL_GetVersion(&linked_time_version); so that the same binary can run on both old and new SDL2 shared libraries.

For example: I'm using Fedora35 with SDL2-2.24.0 and Ubuntu 22.10 with SDL2-2.24.0
Older versions of ubuntu have SDL2 2.0.8 up to 2.0.20

andreas_g

I'll make it depend on SDL 2.24.0. The earlier versions of SDL cause a serious problem while the application window is minimized (100% CPU and 100% GPU usage due to missing VSYNC).

andreas_g

#28
Threaded renderer (faster but less compatible) is now a compile-time option. For now you need to disable it by editing CMakeLists.txt (set ENABLE_RENDERING_THREAD to 0). If someone knows how this can be simplified, please tell me.

The new code is in branch_softfloat (r1243). If you do not have SDL2 v2.26.0 or later you need to comment out line 354 in fast_screen.c (SDL_GetWindowSizeInPixels()). This will be fixed in the release. Now hopefully this resolves all those black screen issues.

andreas_g

In Previous v2.7 you can disable the threaded renderer using the configure script:
./configure --disable-rendering-thread
This should fix the problems with black windows.