Re: udev fixed, but not xorg

[Indigo <pointofavailability@xxxxxxxxx>]

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/