Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fedora 41 / Debian 12 - Workspace not loading #451

Closed
pcardona34 opened this issue Jan 10, 2025 · 41 comments
Closed

Fedora 41 / Debian 12 - Workspace not loading #451

pcardona34 opened this issue Jan 10, 2025 · 41 comments

Comments

@pcardona34
Copy link
Contributor

Hi Sergii,

After building from Packaging/Sources on Fedora 41, I was not able to launch Workspace even with (loginwindow.service) or without (startx) Login.app first.

Logfile.txt
Release.txt
Uname.txt

@trunkmaster
Copy link
Owner

Hi Patrick,

I've already seen that error message "NSColor.m:279 Assertion failed in void initSystemColors(void). couldn't get default system color selectedKnobColor" message on Fedora 41.

If I remember correctly my solution was to setup 'nouveau' driver for NVidia card (I've added nouveau.modeset=1 to kernel boot parameters). It's on MacBook Air 2011.

To sum up: it's definitely not GNUstep or NextSpace problem - it's Xorg/Wayland type of a problem - with nouveau.modeset=1 setting GNOME Wayland session doesn't work correcly but Xorg does. Look into /var/log/Xorg.0.log file - it may has clues to your issue's solution.

@pcardona34
Copy link
Contributor Author

Hi Sergii,
I do not have a Nvidia, but the config.txt at boot add a parameter to the kernel command line loading a v3d driver made by Raspberry Pi Foundation I presume.

@pcardona34
Copy link
Contributor Author

pcardona34 commented Jan 12, 2025

P.S.: Having the same issue now on debian 12 after tweaking Xorg conf to fix resolution/frequency and prevent Login.app flickering. See my Draft Pull request to review code changing attempt at this stage.

@trunkmaster
Copy link
Owner

P.S.: Having the same issue now on debian 12 after tweaking Xorg conf to fix resolution/frequency and prevent Login.app flickering. See my Draft Pull request to review code changing attempt at this stage.

Nice! Looking forward to complete PR.

Just curious: could you please make an install of NextSpace on Debian 12 in virtual machine? Will you have working setup or same problems?

@pcardona34
Copy link
Contributor Author

Hi Sergii,

What machine should be targeted in the VM ?

@pcardona34
Copy link
Contributor Author

P.S.: comparing between NextSpace and GSDE (OnFlapp) implementations, I found several differences worth knowing:

  1. GSDE is able to run with my default screen resolution, without tweaking xorg and xrandr returns : 1920x1080 with 75Hz. While NextSpace and Login.app are flickering and need to be forced at a lower resolution: 1280x900 with 60Hz.
  2. It is not only GWorkspace VS Workspace, but a choice on GNUstep Back: in NextSpace, it is "art", while in GSDE it is "cairo".

Did You have the opportnity to converse with OnFlapp about the GNUstep Back choice ? Has anybody already tried that with NextSpace ?

@theokeist
Copy link

P.S.: comparing between NextSpace and GSDE (OnFlapp) implementations, I found several differences worth knowing:

1. GSDE is able to run with my default screen resolution, without tweaking xorg and `xrandr` returns : `1920x1080` with `75Hz`. While NextSpace and Login.app are flickering and need to be forced at a lower resolution: `1280x900` with `60Hz`.

2. It is not only GWorkspace VS Workspace, but a choice on GNUstep Back: in NextSpace, it is "art", while in GSDE it is "cairo".

Did You have the opportnity to converse with OnFlapp about the GNUstep Back choice ? Has anybody already tried that with NextSpace ?

That would be on time since I wanna start new Slackware install and cannot decide on GNUstep or NEXTspace.

@trunkmaster
Copy link
Owner

P.S.: comparing between NextSpace and GSDE (OnFlapp) implementations, I found several differences worth knowing:

1. GSDE is able to run with my default screen resolution, without tweaking xorg and `xrandr` returns : `1920x1080` with `75Hz`. While NextSpace and Login.app are flickering and need to be forced at a lower resolution: `1280x900` with `60Hz`.

GSDE doesn't use displays and screen management implemented inside SystemKit while NextSpace does. By default, at first start SystemKit uses XRandR mechanism to automatically set resolution best applicable to your hardware. It's same as starting Xorg without any configuration.

2. It is not only GWorkspace VS Workspace, but a choice on GNUstep Back: in NextSpace, it is "art", while in GSDE it is "cairo".

Display resolution setting has nothing to GNUstep Back. GNUstep Back manages drawing and displaying text - it doesn't contain Xorg resolution management. Do you mean something different about GNUstep Back?

Did You have the opportnity to converse with OnFlapp about the GNUstep Back choice ? Has anybody already tried that with NextSpace ?

There's nothing to communicate about - NextSpace more integrated with OS than GSDE. Basically GSDE is a bunch of applications bundled together (and includes part of NextSpace BTW). NextSpace's idea is to be more consistent desktop environment in look/feel as well as OS integration. That's why it contains less applications then GSDE. BTW, now I'm working on more tight integration with D-Bus services (like UPower and UDisks2).

So if you think that resolution management in NextSpace is not appropriate, give me more information about your case. Basically I need to understand 2 things:

  1. What resolution do you expect to get? Is it 1920x1080@75Hz?
  2. What resolution do you get right after the start of Login.app? What do mean by "flickering"?
    Then I'll check code and try to find out what could be the cause of your problem.

@trunkmaster
Copy link
Owner

P.S.: comparing between NextSpace and GSDE (OnFlapp) implementations, I found several differences worth knowing:

1. GSDE is able to run with my default screen resolution, without tweaking xorg and `xrandr` returns : `1920x1080` with `75Hz`. While NextSpace and Login.app are flickering and need to be forced at a lower resolution: `1280x900` with `60Hz`.

2. It is not only GWorkspace VS Workspace, but a choice on GNUstep Back: in NextSpace, it is "art", while in GSDE it is "cairo".

Did You have the opportnity to converse with OnFlapp about the GNUstep Back choice ? Has anybody already tried that with NextSpace ?

That would be on time since I wanna start new Slackware install and cannot decide on GNUstep or NEXTspace.

I guess you've got enough information in my reply to @pcardona34 or something leaves unclear to you?

@pcardona34
Copy link
Contributor Author

pcardona34 commented Feb 3, 2025

Hi Sergii,
Thank You for the clear explanations. I apologize my english: I am French, so I may sometimes use bad words.
What I mean to 'flickering' is something like a bad refreshing that makes lines of the screen move up and down. I think it is related to a bad autoconf 'xorg.conf' setup while trying to load Login.app and that this bad instructions are still there.

About my graphic hardware:

GPU model: Broadcom VideoCore VI.
It provides: H.265 (4Kp60 decode); H.264 (1080p60 decode, 1080p30 encode); OpenGL ES 3.0 graphics.
It uses shared memory.
It is related to overlay: vc4-kms-v3d which is loaded at boot according to /boot/firmware/config.txt

Related instructions:

# Automatically load overlays for detected DSI displays
display_auto_detect=1

# Automatically load initramfs files, if found
auto_initramfs=1

# Enable DRM VC4 V3D driver
dtoverlay=vc4-kms-v3d
max_framebuffers=2

# Don't have the firmware create an initial video= setting in cmdline.txt.
# Use the kernel's default instead.
disable_fw_kms_setup=1

# Run in 64-bit mode
arm_64bit=1

# Disable compensation for displays with overscan
disable_overscan=1

xrandr gives these infos:

Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 7680 x 7680
HDMI-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 509mm x 286mm
   1920x1080     74.97*+  60.00    50.00    59.94
(...)

I shall try a new installation from a clean clone of the repo.

@pcardona34 pcardona34 changed the title Fedora 41 - Workspace not loading Fedora 41 / Debian 12 - Workspace not loading Feb 5, 2025
@pcardona34
Copy link
Contributor Author

Hi Sergii,

I was able to install Nextspace from my branch (Debian12 arm64 pcardona34) on my pi400
with somme install scripts and resources modified and then opened successfully the Workspace.

  • The story:
  1. First, I used startx (no Login.app installed)

At the first launch, the screen was flickering.
In Preferences, I could find the current resolution (HD i.e. 1920x1080 @75Hz) had been detected, but obviously not supported. I downgraded to: 1680x1050 @60Hz, which was successfully applicated and then saved for the next logins.

  1. I did NOT try with Login.app, because I know that the previous tries were unsuccessful and with side effects on Workspace. So I preferred to use XDM Display Manager until now: Workspace loads from XDM. It is OK now at this stage.

Please, see my proposals on the PR finalized.

I will try again under Fedora next week-end following the same method.

@pcardona34
Copy link
Contributor Author

Hi Sergii,

  • Installing and launching Workspace, even from Login.app, is OK now under debian 12 within pi400 SBC.
    Please, see the README_RPI.md inside my finalized PR Rpi aarch64 compatible (obsolete) #456.

  • Also still working on Ultramarine 40 (Fedora like) : there, Workspace generates a core dump.

@trunkmaster
Copy link
Owner

Pattrick, any program may segfault (producing core dump) at a bunch of different reasons. "Workspace generates a core dump" has no information to help me identify and fix bug. Also I don't have aarch64 of any kind to try to reproduce it. You may create more and more issues like this without any hope to get a fix. Sorry.

@pcardona34
Copy link
Contributor Author

I Sergii,
I found the cause of the issues and a workaround.

1- Why is Workspace not loading or just stop doing ?

If You read the log, You can see that some symbols are not found: a bad dynamic linking. But why it does sometimes and sometimes it does not ?

=== Initializing Window Manager ===
2025-01-09 19:35:13.843 Workspace[1909:b36e7020] CoreFoundation: loading CFNetwork at path: /usr/lib/libCFNetwork.so
2025-01-09 19:35:13.844 Workspace[1909:b36e7020] CoreFoundation: failed to dynamically link symbol _CFSocketStreamCreatePair
2025-01-09 19:35:13.844 Workspace[1909:b36e7020] CoreFoundation: failed to dynamically link symbol _CFErrorCreateWithStreamError
2025-01-09 19:35:13.844 Workspace[1909:b36e7020] CoreFoundation: failed to dynamically link symbol _CFStreamErrorFromCFError
2025-01-09 19:35:14.088 Workspace[1909:1909] NSColor.m:279 Assertion failed in void initSystemColors(void). couldn't get default system color selectedKnobColor

When it occurs, on debian 12, it aborts and on Ultramarine (Fedora like) it produces a core (segmentation fault).

I was not able to run debugapp within .xinitrc (no output), but the many tries I did on the past weeks gave me the clue...

  • On the lite images I use to build NeXTspace, I sometimes set the locale (fr_FR.UTF-8) early and sometimes after some tests and logout.

  • So, I found this to to ever happen the same way, even launching the Workspace with startx or from Login.app:

    1. With the native en_GB.UTF-8 locale (because Raspberry is an English project) or the en_US.UTF-8 set, Workspace will load and the log says: "... Welcome to the NexTspace world !"
    2. But every time I changed to the fr_FR.UTF-8 locale, at the next login, Workspace stopped launching and produced the above error log. I did not find it because I was doing other tweaks, so I dit not take immediately the relationship.

Workaround: You must revert to the English locale.

@pcardona34
Copy link
Contributor Author

2. Why are Login.app and Workspace flickering on HD display ?

Obviously, the way Login.app and Workspace are loading is not compatible with the HD resolution: 1920x1080 @75Hz managed by the vc4-3d driver of the VideoCore VI of the Pi400/Pi4 B rev.1.

If I observe the resolutions that work, I notice that:

  • 1680x1050, 1440x900 and 1280x800 have a ratio H/V of 1.6.
  • 1280x1024 has a ratio of 1.25.
  • 1152x864 has a ratio of 1.3333...

And HD: 1920x1080 - which does not work with NeXTspace, but does with other desktops (Pixel, original Windowmaker...) - has a ratio of 1,7777...

In the meanwhile, the workaround is to copy in /etc/X11/xorg.conf a screen-resolution.conf like the following (example for 1440x900 @60Hz):

Section "Screen"
  Identifier "Screen0"
  Device "Card0"
  Subsection "Display"
    Modes "1440x900"
  EndSubsection
EndSection

@trunkmaster
Copy link
Owner

I Sergii, I found the cause of the issues and a workaround.

1- Why is Workspace not loading or just stop doing ?

If You read the log, You can see that some symbols are not found: a bad dynamic linking. But why it does sometimes and sometimes it does not ?

=== Initializing Window Manager ===
2025-01-09 19:35:13.843 Workspace[1909:b36e7020] CoreFoundation: loading CFNetwork at path: /usr/lib/libCFNetwork.so
2025-01-09 19:35:13.844 Workspace[1909:b36e7020] CoreFoundation: failed to dynamically link symbol _CFSocketStreamCreatePair
2025-01-09 19:35:13.844 Workspace[1909:b36e7020] CoreFoundation: failed to dynamically link symbol _CFErrorCreateWithStreamError
2025-01-09 19:35:13.844 Workspace[1909:b36e7020] CoreFoundation: failed to dynamically link symbol _CFStreamErrorFromCFError
2025-01-09 19:35:14.088 Workspace[1909:1909] NSColor.m:279 Assertion failed in void initSystemColors(void). couldn't get default system color selectedKnobColor

Do not take it seriously. It's not critical and CoreFoundation releated.

When it occurs, on debian 12, it aborts and on Ultramarine (Fedora like) it produces a core (segmentation fault).

I was not able to run debugapp within .xinitrc (no output), but the many tries I did on the past weeks gave me the clue...

* On the lite images I use to build NeXTspace, I sometimes set the locale (`fr_FR.UTF-8`) early and sometimes after some tests and logout.

* So, I found this to to ever happen the same way, even launching the Workspace with `startx` or from `Login.app`:
  
  1. With the native `en_GB.UTF-8` locale (because Raspberry is an English project) or the `en_US.UTF-8` set, Workspace will load and the log says: "... Welcome to the NexTspace world !"
  2. But every time I changed to the `fr_FR.UTF-8` locale, at the next login, Workspace stopped launching and produced the above error log. I did not find it because I was doing other tweaks, so I dit not take immediately the relationship.

Workaround: You must revert to the English locale.

Good point, thank you! I've found a place inside GNUstep GUI which incorrectly convert colors doubles into NSString placing , instead of .. I don't have a solution yet but we know cause of a problem at least.

@trunkmaster
Copy link
Owner

2. Why are Login.app and Workspace flickering on HD display ?

Obviously, the way Login.app and Workspace are loading is not compatible with the HD resolution: 1920x1080 @75Hz managed by the vc4-3d driver of the VideoCore VI of the Pi400/Pi4 B rev.1.

If I observe the resolutions that work, I notice that:

* `1680x1050`, `1440x900` and `1280x800` have a ratio H/V of 1.6.

* `1280x1024` has a ratio of 1.25.

* `1152x864` has a ratio of 1.3333...

And HD: 1920x1080 - which does not work with NeXTspace, but does with other desktops (Pixel, original Windowmaker...) - has a ratio of 1,7777...

That's it! I need to understand several things:

  1. Does 1920x1080@75 is a valid resolution@frequency?
  2. If it valid, what's wrong with NextSpace?
    The possible cause of an issue is that NextSpace sets resolution@frequency and other desktops relies on Xorg's automagic setup. If so, I need to recheck initial display resolution setup.
    Could you please show me you xrandr output while running NextSpace ("flickering" case) and other desktop to find difference.

In the meanwhile, the workaround is to copy in /etc/X11/xorg.conf a screen-resolution.conf like the following (example for 1440x900 @60Hz):

Section "Screen"
  Identifier "Screen0"
  Device "Card0"
  Subsection "Display"
    Modes "1440x900"
  EndSubsection
EndSection

It's good temporary solution but not right from a correct NextSpace behavior perspective.

@pcardona34
Copy link
Contributor Author

pcardona34 commented Feb 18, 2025

This is a xrandr output on the same pi400 with the same monitor ACER wired at the HDMI-1 port:

patrick@pi400:~ $ xrandr
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 7680 x 7680
HDMI-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 509mm x 286mm
1920x1080 74.97*+ 60.00 50.00 59.94
1920x1080i 60.00 50.00 59.94
1680x1050 59.88
1280x1024 60.02
1440x900 59.90
1280x800 59.91
1152x864 75.00
1280x720 60.00 50.00 59.94
1024x768 70.07 60.00
800x600 60.32 56.25
720x576 50.00
720x480 60.00 59.94
640x480 66.67 60.00 59.94
720x400 70.08
HDMI-2 disconnected (normal left inverted right x axis y axis)

The context is:

  • WM: LXDE
  • DM: lightdm
  • OS: debian 12.9
  • Linux 6.6.74+rpt-rpi-v8 #\1 SMP PREEMPT Debian 1:6.6.74-1+rpt1 (2025-01-27) aarch64 GNU/Linux

And this one also not flickering, under Ultramarine 40, same computer, last NeXTspace build:

Screen 0: minimum 320 x 200, current 1440 x 900, maximum 7680 x 7680
HDMI-1 connected primary 1440x900+0+0 (normal left inverted right x axis y axis) 509mm x 286mm
1440x900 59.90*+
1920x1080 74.97 + 60.00 50.00 59.94
1920x1080i 60.00 50.00 59.94
1680x1050 59.88
1280x1024 60.02
1280x800 59.91
1152x864 75.00
1280x720 60.00 50.00 59.94
1024x768 70.07 60.00
800x600 60.32 56.25
720x576 50.00
720x480 60.00 59.94
640x480 66.67 60.00 59.94
720x400 70.08
HDMI-2 disconnected (normal left inverted right x axis y axis)

  • WM: Workspace
  • DM: Login.app
  • OS: Ultramarine 40
  • Linux ultramarine 6.12.13-100.fc40.aarch64 #\1 SMP PREEMPT_DYNAMIC Sat Feb 8 17:35:51 UTC 2025 aarch64

@pcardona34
Copy link
Contributor Author

pcardona34 commented Feb 18, 2025

And now the xrandr with the flickering behaviour...

Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 7680 x 7680
HDMI-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 509mm x 286mm
1440x900 59.90 +
1920x1080 74.97 + 60.00 50.00 59.94
1920x1080i 60.00 50.00 59.94*
1680x1050 59.88
1280x1024 60.02
1280x800 59.91
1152x864 75.00
1280x720 60.00 50.00 59.94
1024x768 70.07 60.00
800x600 60.32 56.25
720x576 50.00
720x480 60.00 59.94
640x480 66.67 60.00 59.94
720x400 70.08
HDMI-2 disconnected (normal left inverted right x axis y axis)

  • WM: Workspace
  • DM: Login.app
  • OS: Ultramarine 40
  • Linux ultramarine 6.12.13-100.fc40.aarch64 #\1 SMP PREEMPT_DYNAMIC Sat Feb 8 17:35:51 UTC 2025 aarch64

@pcardona34
Copy link
Contributor Author

Also, I add, in case it could be usefull, the Xorg.log.

var_log_Xorg.0.log

@trunkmaster
Copy link
Owner

Thanks. I guess I've found flickering cause: for some reason "1920x1080i" selected instead of "1920x1080". Have you tried to specify "1920x1080" in xorg.conf? What is the result?

@pcardona34
Copy link
Contributor Author

Yes, it should not use interlaced mode (1080i) with a HD LCD monitor (1080p expected).
I tried many ways of modes setting using cvt command, but none of the xorg.conf.d files I tried was successful.

I attach the EDID (Hex format) of the ACER 57e monitor. Maybe it could be helpful.

EDID_Acer_57e_Hex.txt

@trunkmaster
Copy link
Owner

trunkmaster commented Feb 20, 2025

Have yout tried to specify "1920x1080" in /etc/X11/xorg.conf/screen-resolution.conf like this:

Section "Screen"
  Identifier "Screen0"
  Device "Card0"
  Subsection "Display"
    Modes "1920x1080"
  EndSubsection
EndSection

If so, did it work?

And you don't need to use tools like cvt in modern Xorg. You may use xrandr to switch resolution on the fly like in this example:

$ xrandr --output HDMI-1 --mode 1920x1080

@pcardona34
Copy link
Contributor Author

pcardona34 commented Feb 20, 2025

  1. First boot with the screen-resolution.conf ('1920x1080') above:
  • Login.app: flickering;
  • Log in Workspace: the '1440x900' resolution is set according to previous 'Display Preferences'. Changing to '1920x1080' using the resolutions list: now it is flickering;
  1. Opened a Terminal shell.Setting with: xrandr --output HDMI-1 --mode 1920x1080 and Yeeeh! It works!
  2. Log out to see if Login.app is inheriting the mode as usual. It does, not flickering, it means '1080p'.
  3. Restart the computer...
  4. Go to step 1BIS: but Login.app is flickering again (1080i) ... and it is the same for Workspace using the previous '1920x1080' setting from Preferences.

So, in the case of Login.app, at startup, the resolution-conf_1920.conf is not enough to prevent flickering (falling back to interlaced 1080i). Also, logged in Workspace, again it is flickering (so the way it is set there is also falling to interlaced).
The only way is to force good mode (1080p VS 1080i) using xrandr as above after login.

@pcardona34
Copy link
Contributor Author

P.S.: I was using cvt to get modelines and try more sophisticated screen-resolution.conf, but it was not successful because the driver is doing it from EDID... and, following the above note, it results that it is not efficient this way.

@trunkmaster
Copy link
Owner

I Sergii, I found the cause of the issues and a workaround.

1- Why is Workspace not loading or just stop doing ?

If You read the log, You can see that some symbols are not found: a bad dynamic linking. But why it does sometimes and sometimes it does not ?

=== Initializing Window Manager ===
2025-01-09 19:35:13.843 Workspace[1909:b36e7020] CoreFoundation: loading CFNetwork at path: /usr/lib/libCFNetwork.so
2025-01-09 19:35:13.844 Workspace[1909:b36e7020] CoreFoundation: failed to dynamically link symbol _CFSocketStreamCreatePair
2025-01-09 19:35:13.844 Workspace[1909:b36e7020] CoreFoundation: failed to dynamically link symbol _CFErrorCreateWithStreamError
2025-01-09 19:35:13.844 Workspace[1909:b36e7020] CoreFoundation: failed to dynamically link symbol _CFStreamErrorFromCFError
2025-01-09 19:35:14.088 Workspace[1909:1909] NSColor.m:279 Assertion failed in void initSystemColors(void). couldn't get default system color selectedKnobColor

Do not take it seriously. It's not critical and CoreFoundation releated.

When it occurs, on debian 12, it aborts and on Ultramarine (Fedora like) it produces a core (segmentation fault).
I was not able to run debugapp within .xinitrc (no output), but the many tries I did on the past weeks gave me the clue...

* On the lite images I use to build NeXTspace, I sometimes set the locale (`fr_FR.UTF-8`) early and sometimes after some tests and logout.

* So, I found this to to ever happen the same way, even launching the Workspace with `startx` or from `Login.app`:
  
  1. With the native `en_GB.UTF-8` locale (because Raspberry is an English project) or the `en_US.UTF-8` set, Workspace will load and the log says: "... Welcome to the NexTspace world !"
  2. But every time I changed to the `fr_FR.UTF-8` locale, at the next login, Workspace stopped launching and produced the above error log. I did not find it because I was doing other tweaks, so I dit not take immediately the relationship.

Workaround: You must revert to the English locale.

Good point, thank you! I've found a place inside GNUstep GUI which incorrectly convert colors doubles into NSString placing , instead of .. I don't have a solution yet but we know cause of a problem at least.

Try with latest changes to code tree - it should be fixed now.

@trunkmaster
Copy link
Owner

trunkmaster commented Feb 20, 2025

  1. First boot with the screen-resolution.conf ('1920x1080') above:

    • Login.app: flickering;

    • Log in Workspace: the '1440x900' resolution is set according to previous 'Display Preferences'. Changing to '1920x1080' using the resolutions list: now it is flickering;

    1. Opened a Terminal shell.Setting with: xrandr --output HDMI-1 --mode 1920x1080 and Yeeeh! It works!

    2. Log out to see if Login.app is inheriting the mode as usual. It does, not flickering, it means '1080p'.

    3. Restart the computer...

    4. Go to step 1BIS: but Login.app is flickering again (1080i) ... and it is the same for Workspace using the previous '1920x1080' setting from Preferences.

So, in the case of Login.app, at startup, the resolution-conf_1920.conf is not enough to prevent flickering (falling back to interlaced 1080i). Also, logged in Workspace, again it is flickering (so the way it is set there is also falling to interlaced). The only way is to force good mode (1080p VS 1080i) using xrandr as above after login.

Show me your ~/Library/Preferences/.NextSpace/Displays-<hash number>.config file.

@pcardona34
Copy link
Contributor Author

@pcardona34
Copy link
Contributor Author

pcardona34 commented Feb 22, 2025

As You should expect, after last update, new messages about the display are now available in the console.log:
Example:

=== Starting Workspace ===
2025-02-22 09:20:14.614 Workspace[796:796] Screen: sending OSEScreenDidChangeNotification to GSPublicNotificationCenterType...

@trunkmaster
Copy link
Owner

As You should expect, after last update, new messages about the display are now available in the console.log: Example:

=== Starting Workspace ===
2025-02-22 09:20:14.614 Workspace[796:796] Screen: sending OSEScreenDidChangeNotification to GSPublicNotificationCenterType...

Please ignore this - this debug message means nothing for this issue case.

@trunkmaster
Copy link
Owner

Here it is....

Library_Preferences_dot_NextSpace_Displays_config__at1920.txt

As I assume the user's display configuration is correct and works as expected. Moreover SystemKit doesn't make possible to choose resolution with non-numeric width or height (like 1080i). You may accept it as design flow - I'll think about it later...

The only place in the code that may select intelaced mode is when there's no saved display configuration. In that case the best resolution selected and "best resolution" is simply the first resolution in XRandR output list. To prove this idea I want to ask you to try this:

  • start Xorg
  • get shell on this machine in any way (other virtual terminal or SSH)
  • export DISPLAY variable like this: export DISPLAY=:0.0
  • run xrandr command and paste output here.

I expect to see 1920x1080i at first place in a list of resolutions.

@pcardona34
Copy link
Contributor Author

Hi Sergii,
Here is the output (lxterm under LXDE) :

patrick@pi400:~ $ export DISPLAY=:0.0
patrick@pi400:~ $ xrandr
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 7680 x 7680
HDMI-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 509mm x 286mm
1920x1080 74.97*+ 60.00 50.00 59.94
1920x1080i 60.00 50.00 59.94
1680x1050 59.88
1280x1024 60.02
1440x900 59.90
1280x800 59.91
1152x864 75.00
1280x720 60.00 50.00 59.94
1024x768 70.07 60.00
800x600 60.32 56.25
720x576 50.00
720x480 60.00 59.94
640x480 66.67 60.00 59.94
720x400 70.08
HDMI-2 disconnected (normal left inverted right x axis y axis)

As You can note it, it is not as You expected. It is the 1080p and not the 1080i mode at first position, because my monitor is a LCD one, not a RTC.

@trunkmaster
Copy link
Owner

Hi Sergii, Here is the output (lxterm under LXDE) :

patrick@pi400:~ $ export DISPLAY=:0.0
patrick@pi400:~ $ xrandr
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 7680 x 7680
HDMI-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 509mm x 286mm
1920x1080 74.97*+ 60.00 50.00 59.94
1920x1080i 60.00 50.00 59.94
1680x1050 59.88
1280x1024 60.02
1440x900 59.90
1280x800 59.91
1152x864 75.00
1280x720 60.00 50.00 59.94
1024x768 70.07 60.00
800x600 60.32 56.25
720x576 50.00
720x480 60.00 59.94
640x480 66.67 60.00 59.94
720x400 70.08
HDMI-2 disconnected (normal left inverted right x axis y axis)

As You can note it, it is not as You expected. It is the 1080p and not the 1080i mode at first position, because my monitor is a LCD one, not a RTC.

If 1920x1080 is set by Xorg and not DM or DE then Login.app should work the same way. As I mentioned earlier SystemKit classes (which set initial resolution) set resolution first in XRandR screen resources.

To prove that could please do what I asked to literally? Without DM and DE.

@pcardona34
Copy link
Contributor Author

Hi Sergii,
So I did this:

  1. set init level to console and reboot. Purged the '/etc/X11/xorg.conf.d/' folder.
  2. At tty1:
    sudo X
    Could see then a blanck screen at tty2: X running...
  3. At tty3:
export DISPLAY= :0.0
xrandr

The output is the same above:

Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 7680 x 7680
HDMI-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 509mm x 286mm
1920x1080 74.97*+ 60.00 50.00 59.94
1920x1080i 60.00 50.00 59.94
1680x1050 59.88
etc.

The differences between 1080p and 1080i modes are not only progressive/interlace, but also rates: maybe the 75.00 Hz rate is ignored by Display Preferences and in that context, it is ever a 60 Hz rate: so this could explain the 1080i mode, because, its default rate is 60 Hz VS the 75.00 Hz rate for the 1080p mode.

@trunkmaster
Copy link
Owner

@pcardona34 could you please try to disable screen resolution setup in Login.app and check if it helps?
You can do it by commenting out line

setupDisplays();
to look like this:

    // setupDisplays();

then reinstall and restart Login application:

$ sudo make install
$ sudo systemctl daemon-reload
$ sudo systemctl restart loginwindow

@pcardona34
Copy link
Contributor Author

After the rebuild of Login.app following the above change, I can confirm the loginwindow runs without the 'flickering' issue. Of course, the folder /etc/X11/xorg.conf.d is empty.

@trunkmaster
Copy link
Owner

@pcardona34 I've added a fix. Please check if it works correctly for you.

@pcardona34
Copy link
Contributor Author

Hi Sergii,

  • I confirm the Login flickering issue is fixed now: I built NEXTSPACE from the last updated fork under debian 12.9 and pi400.
  • Although the Login issue is fixed, the Workspace flickering issue with '1920x1080@75Hz' is not yet fixed. I still needed to choose manually another resolution ('1680x1050@60Hz') to adjust that inside the 'Display Prefererences' tab .

To be complete, I also noted that the system has created an 'Outputclass' section in '/etc/X11/xorg.conf.d/99-v3d.conf':

Section "Outputclass"
Identifier "vc4"
MachDriver "vc4"
Driver "modesetting"
Option "PrimaryGPU" "true"
EndSection

The item "MachDriver" makes me think that it is a Kernel mode. The same file exists on other RPI OS debian environments I can observe (Pixel Desktop). But, because it has no bad effect on Login panel, it is not the cause, I presume. Maybe, You could modify 'Workspace/Preferences' apps code according to the efficient way You did with Login ?

@pcardona34
Copy link
Contributor Author

P.S.: today, I built it again inside a virtual machine:

  • the Host is my pi400 debian 12 aarch64 with the same Acer output display...
  • the Client is emulated with qemu-system-aarch64: os is debian 12 arm64 and the virtual display is Spice...

And there, after building NEXTSPACE, guess what happened ? I could choose for Workspace a full screen with a 1920x1080 resolution with a rate @60Hz, but now without flickering ! That confirms the problem is related to that 75Hz with the real display...

@trunkmaster
Copy link
Owner

Great test. It needs more investigation.

Current issue subject is not relevant to problem we're discussing. Would you mind to close this issue and create new with resolution-related subject?

@pcardona34
Copy link
Contributor Author

Please see #465 about 75Hz refresh rate issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants