Announcing tinyx - our X server fork

[Misalf]

Running  startx  a 4th time, Fluxbox does launch (:
Numlock/window-move bug still there with this Xvesa.

Running  startx  a 5th time, it doesn't ):
Running  startx  a ?th time, Fluxbox does launch O.o

I'm obviously doing something totally wrong..

[Misalf]

Hmm, I was just about to report that it would work for me too now.
but.. nope. Only 'partially'.

After trying Xfbdev (which kind of worked but poor performance) I wasn't able to go back to Xvesa even though I did not run backup.

So I did completeley turned off the computer. Booted into Xvesa and had a full desktop immediately (WM running etc). Unfortunately, I can't reproduce this at every re-boot / re-powering.

Sometimes it does work - sometimes it doesn't.

[curaga]

You shouldn't start Xvesa as root, it should be setuid root for normal use. Owner root.root, u+s - the existing X servers are all setup like that.

[Misalf]

Are you sure about root.root ?

Current/Default Xvesa.tcz:

Code: [Select]

$ /bin/ls -l /tmp/tcloop/Xvesa/usr/local/bin/Xvesa
-rwsr-xr-x    1 root     staff       650048 May 20  2009 /tmp/tcloop/Xvesa/usr/local/bin/Xvesa


[curaga]

You're right, only the user matters. There's no reason for the group to be staff though.

[Misalf]

I have also tryed root:root but that does always results in a WM-less desktop at first lauch of  startx  after cold/warm boot. With root:staff it mostly does result in a fully functional desktop including WM. However, in both variants fluxbox often fails to connect to XServer after exiting X and launching  startx  again (without reboot). From a user perspective, it feels like a timing issue (if that makes any sense).

Maybe my graphics card is too exotic:
nvidia GeForce 210
PCIe x16
2.5 GT/s

Screen resolution:
1280x1024

I will get my old netbook back later this day (intel graphics) so I can test this build on another machine.

[curaga]

Quick google for the numlock thing, perhaps related:
http://sourceforge.net/p/fluxbox/bugs/283/

[Misalf]

Thanks. So this bug is not related to Xvesa.
(I'll see if I can find that svn version for myself.)
--
On my netbook, this build of Xvesa seems to run without any issues (1:1 copy of Core files & mydata.tgz).

[coreplayer2]

Thanks. So this bug is not related to Xvesa.
(I'll see if I can find that svn version for myself.)
--
On my netbook, this build of Xvesa seems to run without any issues (1:1 copy of Core files & mydata.tgz).

I believe you'll find this is a Fluxbox inconvenience, try using another WM for a while to verify.

[coreplayer2]

This is probably not the place for this discussion, but interestingly the NumLk issue is not present in Xorg-7.7 + Fluxbox  so it does make me question the origin of this issue

[curaga]

Well there's two places responsible if you read the Solaris bug. Xvesa is only sending a keypress event (like the earlier Solaris X server it seems), not keypress + keyrelease, which then confuses fluxbox as fluxbox is doing its own tracking in a weird way.

The protocol specifies a separate field for modifiers, like "is control pressed", and there's a numlock entry in there too. So why fluxbox is tracking numlock state by the keypresses is weird, but it's also weird why the WM cares about numlock at all.

[curaga]

Test packages now posted at http://tinycorelinux.net/~curaga/
Drop-in replacements for the existing ones, please test.

I updated the numlock logic to act like current Xorg, so Fluxbox should be happy now.

[Misalf]

Regarding the num-lock, Fluxbox is really happy now. Thanks!

BUT, I still need to  startx  several times until I get into X with a WM & extra fonts (tested Fluxbox & JWM so far).
So, for me, it's the same problem as before.

[curaga]

I haven't been able to reproduce that yet, on any WM.

edit: Could you post the cpu specs of where it works and where not? And also "time Xvesa -startbench" too, I wonder if the Nvidia box is slower to modeset or something.

edit2: You can probably avoid the bug by adding the "-noreset" option. Perhaps we should make it the default.

[Juanito]

Before I try, does the fork compile 64-bit?