Re: udev fixed, but not xorg

[Indigo <pointofavailability@xxxxxxxxx>]

Finally, I got better resolution.  The problem turned out not to be
xorg, vesa, or udev - it may be a virtualbox issue, still, but there
is no limitation in the graphics adapter or the vesa driver.  I just
had to add HorizSync and VertRefresh to xorg's configs, and also Modes
"1024x768", as well as a Modeline (which was probably optional) - I
think the conflict stems from the widescreen display on my laptop,
sadly... and I feel a little stupid for not even thinking about that
-- but I learned a lot about edid, cvt, and xorg, anyway.  Next, I'll
try for the 1366x768 (odd) native resolution... thank you all again
for the help and ideas with this.



On Sat, Dec 25, 2010 at 10:09 AM, Thomas Hinterberger <kult-ex@xxxxxx> wrote:
> I switched to here - its stupid to continue this on the mailing list
>
>  http://forum.slitaz.org/index.php?p=/discussion/2311/xorg-cooking-23..12
>
> Am 25.12.2010 13:43, schrieb Thomas Hinterberger:
>>
>> 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/
>>
>>
>
>
> ---
> SliTaz GNU/Linux Mailing list - http://www.slitaz.org/
>
>

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