Re: udev fixed, but not xorg

[ Thread Index | Date Index | More lists.tuxfamily.org/slitaz Archives ]


no the path is ok -

 I just got it working, but only when starting slitaz in text mode

get root
then add tux to the group video and run tazx
get back to tux and run startx

as soon, as I start slitaz with the vesa driver, I end up all the time with a black screen

Am 25.12.2010 12:06, schrieb Thomas Hinterberger:
the biggest problem I think is, that the video drivers are going to /usr/lib/X11/modules/drivers and not to /lib/modules/2.6.36-slitaz/kernel/drivers/video/ when they are installed

Am 24.12.2010 22:59, schrieb Indigo:
Gokhlayeh, thank you for such a well thought reply.  I have been
working on this most of the day and have made some progress.  Yes, you
are absolutely right about the problem.  It is a limitation of the
virtualbox video 'card'.  Xorg is not getting much information about
it, either.  The only problem I found with the intel driver package is
that the right modules aren't added to /etc/rcS.conf -- but it doesn't
work, anyway.  I have not been able to successfully build the guest
additions in my other VM, but I will work more on that, later.  What I
don't understand is why do other distributions give me a higher
resolution, even without them?  According to the vbox documentation,
it's VESA compliant, and the xorg log shows available video modes that
exceed 800x600. (source:  grep -r \* /var/log/Xorg.0.log) -- I will
play with the host settings tomorrow, too.  I wonder, can the guest
additions be packaged?

As for the udev problem, which turns out not to be much of a problem,
the errors are generated before the filesystem is remounted
read-write, so I've not been able to log them... but the gist of it
is: unable to create queue file, read-only filesystem.  I fixed this
by changing rcS so that udev starts right after the filesystem is
remounted, just before fstab is read.  Rohit says it was moved up
intentionally for whatever reason... but again, it's not really a
problem, as it fixes itself before rcS is even done running.

For now, however, I have to pull myself away from this screen...


On Fri, Dec 24, 2010 at 12:25 PM, GoKhlaYeh<gokhlayeh@xxxxxxxxxx> wrote:
On Thu, 23 Dec 2010 18:57:10 -0800
Indigo<pointofavailability@xxxxxxxxx>  wrote:

I never did have any problems with udev, just thought it could be the
cause of the xorg problems, as it's now a dependency since xorg 1.8...
was following this thought, troubleshooting:
https://wiki.kubuntu.org/X/InputConfiguration -- and it seemed
plausible.  For my own situation, it may be related to virtualbox
having it's own video card emulation that is VESA compliant, but needs
guest additions to handle anything more... but that being said, vbox
doesn't have a problem with higher resolutions until slim takes over.
Also, this is a common issue I see on IRC.  Having thoroughly read the
tazx script, I tried 'Xorg -config :1' just to read the file
generated, and something is definitely wrong.  I will look at the
dependencies you suggested and let you know, tomorrow.
Hi Indigo,

We spend some time when I updated Xorg to make intel driver work
out-of-the-box; I know it's not perfect on all hardware, but if my
memory is good it was okay for you after enabling intel KMS in Linux
kernel.

Here you are using virtualbox, and I think there's no problem, just
normal virtualbox guest behavior, as manual explain :
http://www.virtualbox.org/manual/

As you know, virtualbox emulate the hardware when you run something in
it. It includes graphic card : InnoTek Systemberatung GmbH VirtualBox
Graphic Adapter. So, there's no chance that Xorg autodetect an Intel
graphic card, or make run it in any way.

"Graphics. The VirtualBox graphics device (sometimes referred to as VGA
device) is, unlike nearly all other emulated devices, not based on any
physical counterpart. It is a simple, synthetic device which provides
compatibility with standard VGA and several extended registers used by
the VESA BIOS Extensions (VBE)."
Source: http://www.virtualbox.org/manual/ch03.html#guestossupport

Tests I did show me that only 800*600 and 600*480 resolutions are
available with virtualbox-ose running classical SliTaz liveCD&  VESA
driver : it's what says xorg xrandr. The driver which can handle better
resolutions is included in the guest additions.

Now, there's an option in VirtualBox-ose machine configuration : enable
host 3D acceleration capabilities. It means that you have to
install intel driver&  related mesa in host to make it works :
VirtualBox can't use hardware functionnalities if have no software in
your system to make it know how to use them (i.e.: linux kernel
modules).

It also require specific driver in hosted system, as well as a
specific dri module : both host and hosted system have to know how
handle 3D rendering. Theses tools are in guest additions.

That's said, with this option I can get direct rendering without
problems on VirtualBoxed SliTaz using vesa&  rasterized and host and
having direct rendering enabled on hosted. This is the fallback dri and
it's not optimized at all.

Note: I don't know if information about 3D acceleration related
information interest you but it's related to the subject as it shows
how host and hosted system are related and how virtualized hardware is
different than real hardware.

So, the general conclusion is : you need software to use your hardware
on host, and software to use emulated hardware on hosted system to make
it works.

As for the udev issue, setting loglevel="err" (or "debug" for even
more), it appears there definitely is a reason it's failing on boot...
it's just that the process respawns, so it's not a big deal in the
end.  If it's not causing any problems, the status message wouldn't
need to be supressed - we could just fake it, make it say 'success' no
matter what.
When problems happens - and they always happens - having both error
messages and real status is helpful. No real suggestion follow this
consideration, as I don't know what's really going on here, but please
don't forget that when you redirect error messages to /dev/null or fake
status.

Thank you for your quick response - I'll be back at this in the morning.

Hope this help.

--
GoKhlaYeh<gokhlayeh@xxxxxxxxxx>


---
SliTaz GNU/Linux Mailing list - http://www.slitaz.org/


---
SliTaz GNU/Linux Mailing list - http://www.slitaz.org/




---
SliTaz GNU/Linux Mailing list - http://www.slitaz.org/




---
SliTaz GNU/Linux Mailing list - http://www.slitaz.org/


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/