Tiny Core Linux
General TC => General TC Talk => Topic started by: curaga on November 30, 2013, 09:13:57 AM
-
Our current Xvesa and Xfbdev hail from the XFree86 4.8.0 era. Not easy to build with a current environment, and so hard to fix bugs in. They are also somewhat bigger than necessary.
So, as one of the last few users of Xvesa, we're announcing a fork of xorg-server-1.2.0. It's been updated to build in a current environment, had everything unnecessary stripped, and some custom tweaks for user-friendliness and faster startup.
Compared to the existing ~700kb 32-bit binaries, these are ~500kb when built with -Os, while at the same time supporting much more functionality (15 extensions vs 8, DPMS among the most important).
Clone with "git clone http://git.tinycorelinux.net/tinyx" to try it out. Packages may be updated into the next (or next+1) release.
Or grab a release tarball from http://www.tinycorelinux.net/~curaga/tinyx-1.0rc1.tar.bz2 for an easier build.
Test packages available at http://tinycorelinux.net/~curaga/
-
How about some instructions.
I loaded compiletc, autoconf, perl5, automake, libtool, and gettext.
I still can't get it to compile under Core 5.
-
Sure, I think you're missing the X headers - Xorg-7.7-dev should do. libtool-dev is also needed to generate the configure script.
The autofoo are only needed for git builds, for (future) release tarballs only compiletc + Xorg-7.7-dev are enough.
edit: Added libXfont-dev as Xorg-dev's dep.
-
Very nice!
Will get some tcz on the repo soon? There are already some "benchmarks" against the Xvesa? The tinyX will suport more resolutions? Support for Xcompmanger?
Thanks!
-
Interesting news :)
-
TCZ packages will get there in a week or two.
There are already some "benchmarks" against the Xvesa? The tinyX will suport more resolutions? Support for Xcompmanger?
- benchmarks: the main goal for fbdev and vesa is to be small. They have no render acceleration, for that, use Xorg.
- more resolutions: this is not possible, as fbdev uses the existing resolution, and vesa gets the resolutions from your BIOS.
- Xcompmgr: no, composite support is not included. Please use Xorg for this.
As mentioned in the README, a possible future "Xmodesetting" would be able to use any resolution, as long as an open KMS kernel driver existed in graphics-KERNEL.tcz. However, you can already get the best resolution by loading graphics- and Xfbdev, so the new server is not a high priority.
-
With current Xvesa, I can't move windows via mouse (in fluxbox) while numlock is activated. Could this possibly be fixed with this version?
--
I tryed compiling both, git and tarball. Both fail to launch for me.
I did load the mentioned extensions for compiling.
Compiler flags as mentioned in wiki.
For the git version, I did first ran autogen.sh .
$ ./configure --prefix=/usr/local
...
$ make
...
$ make DESTDIR=/tmp/tinyx install-stripCompiling finishes without errors.
I did also try make install with sudo but I guess that doesn't make a difference when 'installing' to /tmp ?
Then I have repacked the current Xvesa.tcz with /usr/local/bin/Xvesa replaced with that newly created one.
I tryed chown root:staff (like default Xvesa), root:root and tc:staff on Xvesa before packing. Always same result:
$ startx gives error: "failed in waitforX"
$ Xvesa gives error: "Server must be suid root"
-
What happens when you try to run it as root?
-
Then it complains about bad resolution and being unable to find fonts - "fixed" in particular.
Same if I add -screen 1280x1024
I will test on a clean install later.
-
With current Xvesa, I can't move windows via mouse (in fluxbox) while numlock is activated. Could this possibly be fixed with this version?
I can't remember off-hand how to resolve this issue but is not related to Xvesa iirc, strangely i've experienced this before once.. though haven't had the issue for a while, then today while trying to duplicate the NumLK/typing/move windows issue with the hope of finding the resolution, I've gone and activated the feature accidentally. So now I have the issue where you can either type or you can move windows, but not both. and i can't remember how I arrived here. Though I believe this is fluxbox related
Nice work on the Xvesa/Xfbdev, after compiling I noticed that Xfbdev is half the size of the version it replaces :thumbup:
going to take them both for a spin here if I can regain control of my keyboard :p
-
Then it complains about bad resolution and being unable to find fonts - "fixed" in particular.
Same if I add -screen 1280x1024
I will test on a clean install later.
Try this:
sudo chmod u+rwxs,a+rx /path/to/Xvesa
-
Sorry about that, my fault in not posting better instructions.
The existing Xvesa had --prefix=/usr, and was later moved to /usr/local. Per this, the bitmap fonts are in /usr. So the recommended configure is:
./configure --with-fontdir=/usr/lib/X11/fonts
This installs to /usr/local but also finds the existing fonts.
-
My first days with tinycore + fluxbox + Xvesa, I thought it would be unstable until I discovered that I just have to re-deactivate the numlock in order to move windows. I have qwertzy layout thus I use the numpad a lot for inserting the '/' character (instead of SHIFT+7). Under Xorg it works.
--
Thanks curaga, I'll try that.
-
./configure --with-fontdir=/usr/lib/X11/fonts
Thanks, Ok will also try this (since I appear to have the same issue with the fonts)
@Misalf I couldn't find which key combo I pressed to change the NumLK/windows position state from having control to not having any control, so I rebooted restoring the Fluxbox default configuration and the numlk window feature is acting normally again in Xvesa. good luck
-
sudo chmod u+rwxs,a+rx /path/to/XvesaDid not help.
--
./configure --with-fontdir=/usr/lib/X11/fontsNow I'm able to lauch sudo Xvesa (allone) but startx still doesn't work.
So I edited ~/.xsession to start Xvesa with sudo and this now results in a seemingly workin X desktop.
Is it OK or even required for Xvesa to be ran as root?
However, after exiting X and running startx again, fluxbox fails to launch (my conky lives, though).
/tmp/wm_errors
Error: Couldn't connect to XServer:0.0(Numlock/window-move bug still there with this Xvesa; but can't test with default fluxbox configs)
running startx for a 3rd time, I also have a wbar.
--
[Don't worry guys, i did not backup so I can go back any time][/code]
-
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..
-
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.
-
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.
-
Are you sure about root.root ?
Current/Default Xvesa.tcz:
$ /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
-
You're right, only the user matters. There's no reason for the group to be staff though.
-
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.
-
Quick google for the numlock thing, perhaps related:
http://sourceforge.net/p/fluxbox/bugs/283/
-
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).
-
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.
-
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
-
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.
-
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.
-
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.
-
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.
-
Before I try, does the fork compile 64-bit?
-
-noreset does totally eliminate the problem.
I exited out of X and re-'startx'ed eleven times and always had a WM and the custom fonts I have installed.
--
I'm not sure what you mean by 'cpu specs'..
My netbook [MSI Wind U100]:
(Xvesa working flawlessly)
- CPU: Intel Atom N270
$ time Xvesa -startbench
Could not init font path element /usr/lib/X11/fonts/TTF/, removing from list!
Could not init font path element /usr/lib/X11/fonts/OTF/, removing from list!
Could not init font path element /usr/lib/X11/fonts/Type1/, removing from list!
Could not init font path element /usr/lib/X11/fonts/100dpi/, removing from list!
Int 10h (0x4F08) failed: 0x034F (function call invalid in this video mode)
real 0m 0.29s
user 0m 0.01s
sys 0m 0.09s(I'm cheating here - this is still the Xvesa I built myself but..)
--
Desktop PC [HP Compaq dc7700]:
(troublesome)
- CPU: Intel Pentium D 925
$ time Xvesa -startbench
Could not init font path element /usr/lib/X11/fonts/TTF/, removing from list!
Could not init font path element /usr/lib/X11/fonts/OTF/, removing from list!
Could not init font path element /usr/lib/X11/fonts/Type1/, removing from list!
Could not init font path element /usr/lib/X11/fonts/100dpi/, removing from list!
Int 10h (0x4F08) failed: 0x034F (function call invalid in this video mode)
real 0m 2.18s
user 0m 0.49s
sys 0m 1.45s(This is with your build)
-
Before I try, does the fork compile 64-bit?
It does, I specifically aimed for 64-bit cleanliness. Even Xvesa compiles, though it will not work (and there's a runtime check to avoid a corrupted display).
@Misalf
Thanks, will change the default to be noreset then. Your PC is quite powerful, but it takes ten times longer to put up a screen than the netbook.
-
Weird.. No problem for me though while you walk-it-around.
xsetup also shows the same display modes as available in current Xvesa.
Tomorrow I'll try Xfbdev on that thing (current Xfbdev performs very bad/slow).
-
Here are my findings with My Radeon X1200. onboot.lst contains Xprogs, aterm, and flwm_topside.
The X driver is loaded manually.
Version - memory used (free) - VSZ of driver ( top)
Xvesa old - 34636 - 26572
Xvesa new - 31548 - 24596
Xfbdev old - 29588 - 7784
Xfbdev new - 30600 - 8392
Xvesa is a little smaller. Xfbdev is a little larger.
I am having some issue with evince2 with these drivers,
The only one that has no problem with evince2 is the old Xfbdev.
All the others generate an error and terminate evince when expanding the window to full screen width.
evince: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
-
@gerald_clark
Sorry for the delay.
I just tried evince2 on 5.1, with its shipping Xvesa, flwm_topside. It maximized without any issues.
As I can't reproduce, is that the full error? Usually X errors also display the major and minor opcodes.
-
Quick question - with the changes being made to move away from VGA to GOP, do you know if VESA will still be available for GOP? If not will a new GOP driver be required? or is it that frame buffer mode from the kernel would cover GOP and tinyx would/could use the frame buffer mode?
TIA!!
-
The kernel framebuffer + Xfbdev work fine on the EFI framebuffer.
-
do you need any special boot codes for Xfbdev to work with the efi framebuffer?
-
'took me a while to get round to it, but tinyx Xvesa compiles to a 356k extension (deps libXfont, libXdmcp, Xorg-fonts) and works fine at my laptop (intel hd3000) native resolution of 1366x768.
The logitech vx nano mouse movement it a little jumpy (as with Xorg and mouse driver, but not with Xorg and evdev driver), but otherwise OK.
evince (gtk3) at 400% is OK, evince2 (gtk2) also OK at 400%
-
No bootcodes needed for efi fb, in my experience it modesets directly to the highest res available.
-
tinyx Xfbdev compiles to an x86_64 extension of 404k compared to current 620k :)
Booting without boot codes looks like it gives 800x600: $ cat /sys/class/graphics/fb0/modes
U:800x600p-75
grub2 command "set gfxpayload='1366x768x24'" has no effect - haven't yet figured out how to query available efi fb modes (and have not yet tried vga=0x318 video=vesafb:mtrr) :(
Logitech vx nano usb mouse is very jittery
evince works at 400%
-
Seems we have conflicting reports, as Gerald said in the other thread that the recompiled evince was still failing.
-
The recompiled evince was x86 gtk2 version, I was testing x86_64 Xfbdev (although I cannot get it to fail with x86 Xvesa or Xorg)
Tracked down and compiled modelist.efi - any ideas where this is run from - grub2 console ignores it, efi console font becomes corrupted when run, not a native linux executable ???
-
No idea, sorry.
-
$ file modelist.efi
modelist.efi: PE32+ executable (EFI application) x86-64 (stripped to external PDB), for MS Windows
..doesn't give much away - interesting that it says windows when compiled with linux
Edit: some progress: grub> videoinfo
List of supported video modes:
Legend: mask/position=red/green/blue/reserved
Adapter: `EFI GOP Driver`:
0x000 1366x768x32 (5464) Direct color mask: 8/8/8/8 pos: 16/8/0/24
0x001 1024x768x32 (4096) Direct color mask: 8/8/8/8 pos: 16/8/0/24
0x002 640x489x32 (2560) Direct color mask: 8/8/8/8 pos: 16/8/0/24
*0x003 800x600x32 (3200) Direct color mask: 8/8/8/8 pos: 16/8/0/24
EDID Version: 1.4
Preferred mode: 1366x768
-
Got it:
$ cat /mnt/sdb1/EFI/BOOT/grub/grub.cfg
loadfont unicode
insmod efi_gop
set gfxmode=1366x768x32
set gfxpayload=keep
set gfxterm_font=unicode
terminal_output gfxterm
search --no-floppy --fs-uuid --set=root f8422ac1-fef4-48ce-b79e-abce5a598e8a
menuentry "rootfspure64" {
linux /boot/vmlinuz64 quiet noswap tce=UUID=f8422ac1-fef4-48ce-b79e-abce5a598e8a waitusb=10:UUID=f8422ac1-fef4-48ce-b79e-abce5a598e8a tz=GMT-4 blacklist=bcma blacklist=ssb blacklist=b43 host=boxdell text
initrd /boot/rootfs64.gz /boot/modules64.gz
}
..and now: $ cat /sys/class/graphics/fb0/modes
U:1366x768p-76
Using flwm classic and moving a window about rapidly results in a relatively slow re-draw, but much better than the current x86_64 Xfbdev.
The mouse movement would get old quickly though :P
-
BTW - when compiling tinyx, wouldn't the expected behaviour of /autogen.sh be to run ./configure automatically - at the moment it just stops?
-
BTW - when compiling tinyx, wouldn't the expected behaviour of /autogen.sh be to run ./configure automatically - at the moment it just stops?
No, it is the convention *not* to run configure inside autogen. I can't recall which distro guidelines that comes from, but I agree with it, as there's no way to run configure --help to check the args, wasting time.
One link from quick google:
http://bugs.mysql.com/bug.php?id=49256
-
BTW what is wrong with your mouse? Is it some gamer edition with a really high sensitivity?
-
Nope, it's a bog standard laptop mouse - logitech vx nano
What happens, perhaps to a varying degree, in Xvesa, Xfbdev and Xorg (with mouse driver) is that when typing the mouse pointer moves on its own and suddenly acts as though it was clicked and you find yourself entering text somewhere else in the document, web page, tc forum reply, etc.
This happens with and without the mouse on a pad +/- 15cm from the keyboard.
This doesn't happen with Xorg and the evdev driver.
-
That sounds like the usual laptop issue of your palms touching the touchpad. If it's the usb mouse, does it behave the same on a desktop too?
-
Probably a stupid question, as everyone on this thread is talking about lightweight DE's and WM's but would E17 and KDE work with Tinyx or would standard X be better suited to run those.
-
bog standard
ROFLMAO I haven't heard that term in a long time.... :)