[Cuis-dev] Space is low

Gerald Klix cuis.01 at klix.ch
Wed Dec 4 09:59:50 PST 2024


On 8/12/24 3:38 PM, Juan Vuletich via Cuis-dev wrote:
> Hi Gerald,
>
> On 8/12/2024 9:40 AM, Gerald Klix via Cuis-dev wrote:
>> Hi Juan,
>>
>> I tested the this issue with FreeBSD on the same
>> (development) machine and with Devuan Daedalus
>> on another machine.
>> My development machine runs Devuan Chimaera.
>>
>> It works perfectly on the other machine.
>> With FreeBSD 14 the same error occurs.
>> The VM for FreeBSD is essentialy the Linux VM,
>> I only disabled the frame-buffer interface.
>> FreeBSD has the newest X-Server version.
>
> Thanks for the update.
>
>> I presume this is related to a buggy X11 implementation
>> or some X11 protocoll corner case the VM does not handle
>> correctly. Since I can not provide instructions to reproduce
>> this issue – after all it works with Xephyr – I suggest
>> I'll watch this issue and when I'll find some means to reproduce it
>> I'll file an error.
>
> Sounds reasonable.
>
>> HTH,
>>
>> Gerald
>>
>> PS: Just before sending this e-mail,
>> I tried the same stunt with the Squeak 6 version at
>> hand. It works.
>
> Well, there are perhaps two differences between Squeak and Cuis that 
> are relevant: One is that the code that checks for changes in the 
> Screen size, and recreates Display as needed is completely different, 
> possibly resulting in a different call pattern to platform primitives 
> and Display memory allocation. The other difference is that by 
> default, VectorCanvas uses additional buffers of Display extent, so 
> memory stress is larger. Cuis can still go back to BitBltCanvas, but 
> you lose the VectorGraphics stuff, going back to a more basic UI api.
>
>> --- X11 versions ---
>>
>> Hape02
>> ======
>> Referred to as „the other machine“.
>>
>> bear at hape02 ~>  sudo Xorg -version
>>
>> X.Org X Server 1.21.1.7
>> X Protocol Version 11, Revision 0
>> Current Operating System: Linux hape02 6.1.0-23-amd64 #1 SMP 
>> PREEMPT_DYNAMIC Debian 6.1.99-1 (2024-07-15) x86_64
>> Kernel command line: BOOT_IMAGE=/@rootfs/boot/vmlinuz-6.1.0-23-amd64 
>> root=UUID=9abcba3f-4d1e-43d7-b63d-a132346c8301 ro 
>> rootflags=subvol=@rootfs quiet
>> xorg-server 2:21.1.7-3+deb12u7devuan1 
>> (https://www.devuan.org/os/community)
>> Current version of pixman: 0.42.2
>>     Before reporting problems, check http://wiki.x.org
>>     to make sure that you have the latest version.
>>
>>
>> Speedy
>> ======
>> My „development machine“.
>>
>> Linux
>> -----
>> bear at speedy ~ [127]>  sudo Xorg -version
>> [sudo] password for bear:
>>
>> X.Org X Server 1.20.11
>> X Protocol Version 11, Revision 0
>> Build Operating System: linux Debian
>> Current Operating System: Linux speedy 5.10.0-31-amd64 #1 SMP Debian 
>> 5.10.221-1 (2024-07-14) x86_64
>> Kernel command line: dozfs=force root=ZFS=zos/root/devuan 
>> pcie_aspm=off rw initrd=devuan\initrd.img-5.10.0-31-amd64
>> Build Date: 10 April 2024  08:59:35AM
>> xorg-server 2:1.20.11-1+deb11u13 (https://www.debian.org/support)
>> Current version of pixman: 0.40.0
>>     Before reporting problems, check http://wiki.x.org
>>     to make sure that you have the latest version.
>>
>> FreeBSD
>> -------
>> bear at speedy ~ [1]>  sudo Xorg -version
>>
>> X.Org X Server 1.21.1.13
>> X Protocol Version 11, Revision 0
>> Current Operating System: FreeBSD speedy 14.1-RELEASE-p3 FreeBSD 
>> 14.1-RELEASE-p3 GENERIC amd64
>>
>> Current version of pixman: 0.42.2
>>     Before reporting problems, check http://wiki.x.org
>>     to make sure that you have the latest version.
>>
>
> Thanks,
>
The recent Cuis meeting reminded me to give an update on that topic.

In a nutshell: The problem is gone (not solved).

A month ago I went totally crazy and bought another pair of 3840x2160 
displays.
Before that my X11 (xrandr) display configuration looked like this

xrandr --output DisplayPort-1 --mode 3840x2160 --pos 1920x0 --rotate 
left --output DisplayPort-0 --off --output DisplayPort-2 --mode 
3840x2160 --pos 4080x0 --rotate left --output HDMI-A-0 --off --output 
DVI-D-0 --mode 1920x1080 --pos 0x1168 --rotate normal --transform none 
--panning 6240x3840+0+0

Now it looks like this:

xrandr --output DisplayPort-0 --primary --mode 3840x2160 --pos 0x0 
--rotate left --output DisplayPort-1 --mode 3840x2160 --pos 6480x0 
--rotate left --output DisplayPort-2 --mode 3840x2160 --pos 4320x0 
--rotate right --output HDMI-A-0 --mode 3840x2160 --pos 2160x0 --rotate 
left --output DVI-D-0 --mode 1920x1080 --pos 8640x0 --rotate normal

If you take a closer look, you discover that the small monitor's 
configuration lacks
the big virtual panning screen (6240x3840).
I used that display as some sort of looking glass.
Without the panning option everything works fine.

The OSVM needs a Wayland display.
As much as I like X11, I am under the impression, that you can
count the number of capable X11 maintainers by using the fingers
of your left hand.
I hope Smalltalk will fare better.


Best Regards,

Gerald Klix


More information about the Cuis-dev mailing list