Guys and Pascal in special, please update mesa to latest version (9.0.1)
Talks about cooking status/bugs/suggestions/etc(174 posts) (21 voices)
may i ask for an info?
would the mesa update prevent i915 to be auto-loaded or it's for some other reason?
terminus seems good, if i must find something wrong maybe a little thin for little screen
had to install kbd package to test it.
i think that you are working on upgrading mesa
i tried myself for the sake of curiosity and i think that llvm is required.
being llvm.org down i built llvm using debian original source and configure options form LFS:
SHORT_DESC="Modular e compiler toolchain collection"
# Rules to configure and make the package.
make && make install
# Rules to gen a SliTaz package suitable for Tazpkg.
mkdir -p $fs/usr/bin
cp -a $install/usr/bin/* $fs/usr/bin
mkdir -p $fs/usr/include
cp -a $install/usr/include/* $fs/usr/include
mkdir -p $fs/usr/lib
cp -a $install/usr/lib/* $fs/usr/lib
it took ages to build but with it i can build mesa (adding llvm and libtool as build depends)
just trying to help, i would not post this if llvm was up, i don't want to do your job :-)
@Aleksej to test your terminal font
how can I switch to german keyboard on console - setxkbmap de works only for X
sorry - it is tazkeymap..
the only key not working is ~ but this is also not working in X, I can do it only with the english keyboard
please, rename nouveau driver to nouveau_vieux (NV04 - NV20), as it doesn't support any newer cards.
Also, I'd suggest adding llvm dependency, as almost everyone switched to and works faster and better with gallium3d (geforce FX and later, radeon 9500 and later, intel gma950)
If you pass parameters to kernel LANG=de (if I recall correctly) then you already have german keyboard. Init script do the job for you.
Pure linux way:
# loadkeys de
While you can change font without root permissions.
@Aleksej LANG=de is not working in rolling - see the beginning of the thread - it hangs on searching soundcard
exploring the vesa bug - I found something:
ignoring device with a bound kernel driver
(WW) Falling back to old probe method for vesa
This is vesa-specific and leads to http://cgit.freedesktop.org/xorg/driver/xf86-video-vesa/commit/?id=b1f7f190f9d4f2ab63d3e9ade3e7e04bb4b1f89f
so I try to find, whats blocking thevideo card and I cannot find something in dmesg
I attach it, perhaps somebody else can see something
Probably because it should be something like lang=de_DE - I know it's something weird like that.
if you have intel it's i915 : lsmod | grep i915
maybe rebuilding xf86-xorg-video-vesa without the patch you find would ignore loaded kernel modules bound to a graphic card.
i tried to build xf86-xorg-video-vesa reversing the patch you found, X starts but the output translate upwards and you loose the top panel, probably i915 interferes and there was a reason why vesa's developers introduced the patch.
please, could you try my patched version of spacefm here
it calls tazbox as default su app, you can check if it works opening a root window (menu file)
to install my version you should remove spacefm, rm -r /home/ $USER/.config/spacefm then logout.
this is required because there is a spacefm --desktop in the background so new package would not be loaded.
then login again and install my package, now it should works.
please, let me know what happens, thanks
@Aleksej sorry - only the first line was for you, all the rest relating the xorg bug
your patch of spacefm works perfect - thanks a lot
I just found in Xorg.0.log, whats blocking the video card:
[ 675.662] (II) Loader magic: 0x81df690
[ 675.662] (II) Module ABI versions:
[ 675.662] X.Org ANSI C Emulation: 0.4
[ 675.662] X.Org Video Driver: 12.0
[ 675.662] X.Org XInput driver : 16.0
[ 675.662] X.Org Server Extension : 6.0
[ 675.664] (--) PCI:*(0:0:2:0) 8086:2592:1043:82d9 rev 4, Mem @ 0xf7f00000/524288, 0xd0000000/268435456, 0xf7ec0000/262144, I/O @ 0x0000ec00/8
[ 675.664] (--) PCI: (0:0:2:1) 8086:2792:1043:82d9 rev 4, Mem @ 0xf7f80000/524288
by the way, its quite stupid, that dmesg.log stopps, as soon as X starts....
but this should not be the problem, because this exists in 4.0 also
I do not find real differences until:
[ 136.253] (WW) xf86OpenConsole: setpgid failed: Operation not permitted
[ 136.259] vesa: Ignoring device with a bound kernel driver
these 2 Xorg.0.log are from the Thinkpad X31 one from 4.0, one from rolling - that one earlier was fromm an EEE-PC
I just remembered, that the old rolling from 04. 09. booted with vesa on my Portege R100 - and still it is doing so
so next I will try the rolling from now - but takes 30 min to boot
the same with actual rolling
There is a funny thing with the R100 - I have to type 2 x startx until it starts....
You must log in to post.