Tiny Core 16.0 Alpha 1 Testing

[MikeLockmoore]

Hi MikeLockmoore
Open a terminal and try this under fltk-1.4:

Code: [Select]

export FLTK_SCALING_FACTOR=1.3
apps
Does that help you with regard to scaling fltk apps?

That works, and is pretty slick!  I think what I'd like to do for FLWM is have it check for that environment variable, and if it is already set to something other than 1.0, use it.  If it is not set, or set to 1.0, check the Xft.dpi setting in .Xdefaults, and set that FLTK_SCALING_FACTOR according to the ratio of the Xft.dpi / 96.0  (e.g. 120.0 / 96.0 = 1.25), and scale the titlebar characters according to that ratio too, because the titlebar is not affected by the FLTK-1.4 application scaling.  I've not dug in enough to see if I can re-scale the titlebar every time the inner FLTK_SCALING_FACTOR is changed, but at least it could be done once at FLWM startup.

[Rich]

Hi MikeLockmoore

... I've not dug in enough to see if I can re-scale the titlebar every time the inner FLTK_SCALING_FACTOR is changed, but at least it could be done once at FLWM startup.

I think  FLTK_SCALING_FACTOR  needs to be exported before starting
the window manager. ~/.profile seems like the right place to do this.
I'm not aware of any way to change it's exported value after starting
the window manager.

[Rich]

Hi Juanito

Using tc-16.x and Xorg-7.7, I can start the gui once, although there is a faint coloured band at the top of the screen, which disappears once the gui is fully started.

If I try to exit to the console prompt I get a blank screen or a screen with a couple of green squares only recoverable by cycling the power. ...

I see a band with 1/4 inch wide vertical stripes across the top of the screen
before the GUI shows up. I can exit to the console prompt and startx starts
the GUI again.

[Juanito]

After I tried to update xorg-server and it failed to start, I got an interesting explanation from the xorg-server people:

From what I understand, the Xorg's fbdev driver filters out PCI devices, because they have a DRM driver available. It only binds to things like efifb, which is on the platform bus. The actual PCI graphics device has a DRM driver and is supported by Xorg's modeset driver.

Xorg detected this before kernel 6.9, but looked at the wrong place in sysfs. With kernel 6.9 it broke and therefore Xorg's fbdev would bind to PCI devices. That's why it worked. After we fixed Xorg in the cited commit, the filter is back and working as intented. If you revert that commit and go back to a kernel before 6.9, I'm sure it would filter it out either.

So yeah, I'm sure this isn't a bug. If you want fbdev on this hardware, you have to set it manually.

The latest state of play, on my intel haswell hardware at least is:

64-bit without graphics-KERNEL: fbdev doesn't work, but uses xf86-video-vesa
64-bit with graphics-KERNEL: both modesetting and xf86-video-intel work

32-bit without graphics-KERNEL: fbdev doesn't work, but uses xf86-video-vesa - hangs on exit to console prompt
32-bit with graphics-KERNEL: modesetting hangs, xf86-video-intel works