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/