Tiny Core Linux
Tiny Core Extensions => TCE Bugs => Topic started by: andyj on January 14, 2026, 03:58:47 PM
-
In TC 15 and previous versions Xorg could see changes to the layout:
tc@box:~$ tail -fs1 /var/log/Xorg.0.log
[ 8.383] (**) ImPS/2 Generic Wheel Mouse: (accel) acceleration threshold: 4
[ 8.383] (II) VMWARE(0): VMMOUSE DEVICE_ON
[ 8.383] (II) VMWARE(0): vmmouse enabled
[ 8.383] (II) config/udev: Adding input device ImPS/2 Generic Wheel Mouse (/dev/input/mouse0)
[ 8.383] (II) No input driver specified, ignoring this device.
[ 8.383] (II) This device may have been added with another device file.
[ 8.383] (II) config/udev: Adding input device PC Speaker (/dev/input/event3)
[ 8.383] (II) No input driver specified, ignoring this device.
[ 8.383] (II) This device may have been added with another device file.
[ 9.106] (II) VMWARE(0): vmmouse enable absolute mode
[ 27.756] (!!) vmware(0): New layout.
[ 27.756] (!!) vmware(0): 0: 0 0 1920 1080
[ 27.756] (!!) vmware(0):
[ 43.243] (!!) vmware(0): New layout.
[ 43.243] (!!) vmware(0): 0: 960 1080 1920 1080
[ 43.243] (!!) vmware(0): 1: 0 0 1920 1080
[ 43.243] (!!) vmware(0):
[ 52.263] (!!) vmware(0): New layout.
[ 52.263] (!!) vmware(0): 0: 1920 0 1920 1080
[ 52.263] (!!) vmware(0): 1: 0 0 1920 1080
[ 52.263] (!!) vmware(0):
[ 57.625] (!!) vmware(0): New layout.
[ 57.625] (!!) vmware(0): 0: 1920 1080 1920 1080
[ 57.625] (!!) vmware(0): 1: 960 0 1920 1080
[ 57.625] (!!) vmware(0): 2: 0 1080 1920 1080
[ 57.625] (!!) vmware(0):
[ 66.093] (!!) vmware(0): New layout.
[ 66.093] (!!) vmware(0): 0: 0 0 1920 1080
[ 66.093] (!!) vmware(0):
This comes from switching to full screen and cycling through multiple monitors (the Slackware host has three) in the VMware Workstation menu bar.
In TC 16+ the "vmwgfxctrl --print-topology" prints the same information as in previous releases when cycling through multiple monitors, but nothing changes on the desktop and nothing is in Xorg.0.log like it's not even happening.
All TC versions 15+ have the latest open-vm-tools 13.0.5 installed built from the same source file today.
What changed in Xorg between TC 15 and 16? BTW it doesn't work on 17 alpha either.
-
Might be this, from Xorg.0.log:
[ 4.043] (II) LoadModule: "vmware"
[ 4.043] (II) Loading /usr/local/lib/xorg/modules/drivers/vmware_drv.so
[ 4.048] (EE) Failed to load /usr/local/lib/xorg/modules/drivers/vmware_drv.so: libxatracker.so.2: cannot open shared object file: No such file or directory
[ 4.048] (EE) Failed to load module "vmware" (loader failed, 0)
$ grep libxatracker *list
Xorg-7.7-3d.tcz.list:/usr/local/lib/libxatracker.so
Xorg-7.7-3d.tcz.list:/usr/local/lib/libxatracker.so.2
Xorg-7.7-3d.tcz.list:/usr/local/lib/libxatracker.so.2.5.0
Apparently this was part of Xorg-7.7-3d, but now that it's a meta package, this library is nowhere to be found in TC 16+
-
What changed in Xorg between TC 15 and 16? BTW it doesn't work on 17 alpha either.
At some point after mesa-24.1.7 the libraries provided by the mesa source code changed significantly (some were added, some disappeared), which prompted a refactoring of the extensions containing the libraries.
Let me check if building the latest xf86-video-vmware changes anything.
-
This exists in mesa-24.1.7
option(
'gallium-xa',
type : 'feature',
deprecated: {'true': 'enabled', 'false': 'disabled'},
description : 'enable gallium xa frontend.',
)..but not in mesa-25.2.5
xf86-video-vmware-13.4.0 configure gives this: checking for XATRACKER... no
checking whether to build Kernel Mode Setting and 3D... no
So far I haven't found any vmware fixes
-
I posted the updated test extension without the dep on libxatracker at: http://tinycorelinux.net/16.x/x86_64/tcz/src/xorg/xf86-video-vmware/
Maybe you could try it out?
-
The test version does not see the correct starting layout, and "vmwgfxctrl --print-topology" doesn't show any changes. As a bonus, when I exit to prompt, the screen has a low color sunset like gradient going from orange to pink. No text visible, I have to send ctl-alt-del to restart the VM.
In the test version "ldd /usr/local/lib/xorg/modules/drivers/vmware_drv.so" gives:
linux-vdso.so.1 (0x00007fe6b28ed000)
libc.so.6 => /lib/libc.so.6 (0x00007fe6b273c000)
/lib/ld-linux-x86-64.so.2 (0x00007fe6b28ef000)
In TC 15, "ldd /usr/local/lib/xorg/modules/drivers/vmware_drv.so" gives:
linux-vdso.so.1 (0x00007ffc2f5f0000)
libdrm.so.2 => /usr/local/lib/libdrm.so.2 (0x00007f0987df2000)
libxatracker.so.2 => /usr/local/lib/libxatracker.so.2 (0x00007f0987841000)
libudev.so.0 => /usr/local/lib/libudev.so.0 (0x00007f0987600000)
librt.so.1 => /lib/librt.so.1 (0x00007f098783c000)
libc.so.6 => /lib/libc.so.6 (0x00007f098740d000)
libz.so.1 => /usr/lib/libz.so.1 (0x00007f0987826000)
libzstd.so.1 => /usr/local/lib/libzstd.so.1 (0x00007f0987376000)
libLLVM-15.so => /usr/local/lib/libLLVM-15.so (0x00007f0982cca000)
libexpat.so.1 => /usr/local/lib/libexpat.so.1 (0x00007f0982ca7000)
libdrm_nouveau.so.2 => /usr/local/lib/libdrm_nouveau.so.2 (0x00007f098781a000)
libdrm_intel.so.1 => /usr/local/lib/libdrm_intel.so.1 (0x00007f0982c87000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f098298f000)
libm.so.6 => /lib/libm.so.6 (0x00007f09828cb000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f09828a6000)
/lib/ld-linux-x86-64.so.2 (0x00007f0987e35000)
libffi.so.7 => /usr/local/lib/../lib/libffi.so.7 (0x00007f098780f000)
libdl.so.2 => /lib/libdl.so.2 (0x00007f09828a1000)
libncursesw.so.6 => /usr/local/lib/../lib/libncursesw.so.6 (0x00007f0982844000)
libxml2.so.2 => /usr/local/lib/../lib/libxml2.so.2 (0x00007f0982719000)
libpciaccess.so.0 => /usr/local/lib/libpciaccess.so.0 (0x00007f098270e000)
liblzma.so.5 => /usr/local/lib/../lib/liblzma.so.5 (0x00007f09826e5000)
It seems like it should have some drm dependencies like before. I tried copying libxatracking.so from TC 15 to 17, but it has a dependency on LLVM 15 that I couldn't fake with a simple symlink.
-
I added a version of llvm15-lib that should work alongside llvm19-lib for your test: http://tinycorelinux.net/16.x/x86_64/tcz/src/xorg/xf86-video-vmware/
-
All that resolves the dependencies, but when I startx it fails because vmware_drv.so dumps a backtrace:
[ 190.086] (II) LoadModule: "vmware"
[ 190.086] (II) Loading /usr/local/lib/xorg/modules/drivers/vmware_drv.so
[ 190.092] (EE)
[ 190.092] (EE) Backtrace:
[ 190.093] (EE) 0: /usr/local/lib/xorg/Xorg (xorg_backtrace+0x56) [0x55b61289aaac]
[ 190.093] (EE) 1: /usr/local/lib/xorg/Xorg (0x55b61279f000+0xfc5f0) [0x55b61289b5f0]
[ 190.093] (EE) 2: /lib/libc.so.6 (0x7f34d346b000+0x34bc0) [0x7f34d349fbc0]
[ 190.093] (EE) 3: /lib/libc.so.6 (0x7f34d346b000+0x6cb21) [0x7f34d34d7b21]
[ 190.093] (EE) 4: /lib/libc.so.6 (gsignal+0x12) [0x7f34d349fb4d]
[ 190.093] (EE) 5: /lib/libc.so.6 (abort+0xd3) [0x7f34d348f499]
[ 190.093] (EE) 6: /usr/local/lib/libLLVM.so.19.1 (_ZN4llvm18report_fatal_errorERKNS_5TwineEb+0x15b) [0x7f34cbdea899]
[ 190.093] (EE) 7: /usr/local/lib/libLLVM.so.19.1 (0x7f34cb2d5000+0x1048e38) [0x7f34cc31de38]
[ 190.093] (EE) 8: /usr/local/lib/libLLVM.so.19.1 (0x7f34cb2d5000+0x1048f6b) [0x7f34cc31df6b]
[ 190.094] (EE) 9: /usr/local/lib/libLLVM-15.so (0x7f34c5eb1000+0x8ef173) [0x7f34c67a0173]
[ 190.094] (EE) 10: /lib/ld-linux-x86-64.so.2 (0x7f34d3fb7000+0x3612) [0x7f34d3fba612]
[ 190.094] (EE) 11: /lib/ld-linux-x86-64.so.2 (0x7f34d3fb7000+0x3706) [0x7f34d3fba706]
[ 190.094] (EE) 12: /lib/ld-linux-x86-64.so.2 (_dl_catch_exception+0x34) [0x7f34d3fb838f]
[ 190.094] (EE) 13: /lib/ld-linux-x86-64.so.2 (0x7f34d3fb7000+0x8599) [0x7f34d3fbf599]
[ 190.094] (EE) 14: /lib/ld-linux-x86-64.so.2 (_dl_catch_exception+0x83) [0x7f34d3fb83de]
[ 190.094] (EE) 15: /lib/ld-linux-x86-64.so.2 (0x7f34d3fb7000+0x899b) [0x7f34d3fbf99b]
[ 190.094] (EE) 16: /lib/libc.so.6 (0x7f34d346b000+0x6837d) [0x7f34d34d337d]
[ 190.094] (EE) 17: /lib/ld-linux-x86-64.so.2 (_dl_catch_exception+0x83) [0x7f34d3fb83de]
[ 190.094] (EE) 18: /lib/ld-linux-x86-64.so.2 (0x7f34d3fb7000+0x1431) [0x7f34d3fb8431]
[ 190.094] (EE) 19: /lib/libc.so.6 (0x7f34d346b000+0x67fca) [0x7f34d34d2fca]
[ 190.094] (EE) 20: /lib/libc.so.6 (dlopen+0x64) [0x7f34d34d33e9]
[ 190.094] (EE) 21: /usr/local/lib/xorg/Xorg (0x55b61279f000+0x12adf3) [0x55b6128c9df3]
[ 190.094] (EE) 22: /usr/local/lib/xorg/Xorg (xf86LoadModules+0x92) [0x55b6128b4774]
[ 190.094] (EE) 23: /usr/local/lib/xorg/Xorg (InitOutput+0x922) [0x55b6128b924d]
[ 190.094] (EE) 24: /usr/local/lib/xorg/Xorg (0x55b61279f000+0x3ac19) [0x55b6127d9c19]
[ 190.094] (EE) 25: /lib/libc.so.6 (0x7f34d346b000+0x24b17) [0x7f34d348fb17]
[ 190.094] (EE) 26: /lib/libc.so.6 (0x7f34d346b000+0x24c53) [0x7f34d348fc53]
[ 190.094] (EE) 27: /usr/local/lib/xorg/Xorg (_start+0x21) [0x55b6127da901]
[ 190.094] (EE)
[ 190.094] (EE)
Fatal server error:
[ 190.094] (EE) Caught signal 6 (Aborted). Server aborting
[ 190.094] (EE)
[ 190.094] (EE)
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
[ 190.094] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[ 190.094] (EE)
[ 190.094] (EE) Server terminated with error (1). Closing log file.
The dueling LLVM versions seems like it could be a problem.
-
I uploaded libxatracker built from mesa-24.1.7 against llvm19: http://tinycorelinux.net/16.x/x86_64/tcz/src/xorg/xf86-video-vmware
This would need the original xf86-video-vmware extension, not the test version.
-
Kinda almost works. Resizing the window works as expected. I can cycle through monitors, but when I switch from three back to one is when things go sideways. There isn't an error message in Xorg.0.log or messages, it's just broken in combination of ways I don't know how to explain. The output in Xorg.0.log looks right with regards to the layout changes. I have to use the Restart menu option to get it back to where I can use it. I know this isn't anything to go on, if there is any tracing I could turn on I could try that.
-
Hi andyj
Is drm.ko.gz loaded? If it is, it has some debugging options:
parm: edid_fixup:Minimum number of valid EDID header bytes (0-8, default 6)
parm: debug:Enable debug output, where each bit enables a debug category.
Bit 0 (0x01) will enable CORE messages (drm core code)
Bit 1 (0x02) will enable DRIVER messages (drm controller code)
Bit 2 (0x04) will enable KMS messages (modesetting code)
Bit 3 (0x08) will enable PRIME messages (prime code)
Bit 4 (0x10) will enable ATOMIC messages (atomic code)
Bit 5 (0x20) will enable VBL messages (vblank code)
Bit 7 (0x80) will enable LEASE messages (leasing code)
Bit 8 (0x100) will enable DP messages (displayport code)
parm: timestamp_precision_usec:Max. error on timestamps [usecs]
parm: vblankoffdelay:Delay until vblank irq auto-disable [msecs] (0: never disable, <0: disable immediately)
-
I uploaded a new xf86-video-vmware built from the latest git clone against the libxatracker uploaded earlier: http://tinycorelinux.net/16.x/x86_64/tcz/src/xorg/xf86-video-vmware
Maybe that will work better?
-
Much better. But...
Initially when I click on an app in wbar it opens at the upper left of the display. After I cycle through the monitors everything looks ok, but apps from wbar will now open in the middle of the display. ??? It stays like this after I cycle monitors again, it doesn't move after the first time. I didn't notice anything else right away, I'll have to pressure test it later.
The xf86-video-vmware.tcz.dep file is missing Xorg-7.7-3d.tcz.
I tried the debug thing, I didn't get what I wanted:
tc@box:~$ cat /etc/modprobe.conf
# /etc/modprobe.conf: Modprobe config file.
#
options drm debug=0x1b7
tc@box:~$ sudo cat /sys/module/drm/parameters/debug
0
What am I doing wrong here?
One thing that would be nice is if there was a way to run ~/.setbackground whenever the display resolution changes. Is it possible to set up a trigger for this?
-
One thing that would be nice is if there was a way to run ~/.setbackground whenever the display resolution changes. Is it possible to set up a trigger for this?
Since you are booting into an Xorg environment try arandr
Unfortunately it only gets processed once.....as you boot into Xorg
You would need to create multiples and then try in a terminal run each one-----with the danger
going from large resolution to smaller....to make fonts look bigger etc.....it can be clunky
-
What am I doing wrong here?
No idea.....but I have an alternative.
In my bootloader grub I have "blacklist=snd-hda-intel" and I have a number of sound packages in my bootlist that are not relevant to you
2) I have a ~/.X.d/misc with full contents as below .....perm 644
numlockx on
/home/tc/.local/bin/sound &
Yes there is no shebang
contents of ~.local/bin/sound...perm 755
#!/bin/sh
sudo modprobe snd-hda-intel options enable=0,1
sleep 3
sudo /usr/local/sbin/alsactl restore -f /home/tc/asound.state
so try making a file ~/.local/bin/drmconfig where you attempt something like
#!/bin/sh
sudo modprobe drm options debug=something
I am not a coder but online conversion of hex to dec suggests 439?
438 if that is what you are after appears to be 1B6
-
Once you have the correct setting you know how to test for....try create
/etc/modprobe.d/drm.conf perm 644
contents
options drm debug=something
add etc/modprobe.d/drm.conf to your /opt/.filetool.lst
remove the blacklist ....the file under .X.d and the .local/bin/drmconfig file
-
I tried the debug thing, I didn't get what I wanted:
tc@box:~$ cat /etc/modprobe.conf
# /etc/modprobe.conf: Modprobe config file.
#
options drm debug=0x1b7
tc@box:~$ sudo cat /sys/module/drm/parameters/debug
0
What am I doing wrong here?
What I thought I was showing with this is that the parameter set (or not in this case) in modprobe.conf was not being picked up by modprobe. I apologize for the confusion. My question still stands, why isn't modprobe picking up the parameter in modprobe.conf?
-
One thing that would be nice is if there was a way to run ~/.setbackground whenever the display resolution changes. Is it possible to set up a trigger for this?
I'm using a gradient set in ~/.setbackground:
#!/bin/sh
hsetroot -add "#1B79B8" -add "#AF77CC" -gradient 0
[ $(which wbar.sh) ] && wbar.sh
It would be nice if I could cause this or something like this to run when the resolution changes so I don't get a tiled gradient. It might be helpful if when the wallpaper dialog creates this script that it insert a second line something like "# Created by TC Wallpaper app date/time"
-
Some pressure testing blew a gasket. After a few cycles of the monitors FLWM just went away. I didn't find a dump anywhere. This got me thinking that the dialog moving issue isn't from vmware_drv but from flwm not liking all the resolution changes. Any way to start flwm with debug or tracing?
-
Much better. But...
libxatracker is from the last version of mesa to support it - mesa-24.1.7 - (the xatracker code in mesa was supplied by vmware)
xf86-video-vmware is from https://gitlab.freedesktop.org/xorg/driver/xf86-video-vmware last (cosmetic) commit 25/07/12
i.e. it's not going to get any better than that for the moment - would you like me to post the extensions, or would you like to continue testing?
-
I've made a lot of hand changes, running tce-update and seeing if it continues to work would be the next logical test. Let's post it to TC 16 and 17 and once it hits my mirror I try it.
-
posted to tc-16.x/17.x x86_64 repos
I'll look at x86 once we've finished testing this.