-   Grafpup (
-   -   Xorgwizard with older monitor (

emlsnws 07-05-2007 12:21 PM

Xorgwizard with older monitor

Using the Xorgwizard with an older monitor, one that doesn't return data to ddcprobe, seems to cause a problem.

I'm using 2.0final, and initially set up the machine using a Dell monitor (DELe008). Then I moved the machine onto an Ilyama vision master type monitor. It's 2000 vintage, which you would think has DDI data, but it seems not. (Or maybe my monitor has a broken pin on the connector, etc. etc).

I went through the xorgwizard, manually giving the size of screen I wanted (1024x768) and I have a file called /etc/X11/xorg.conf.VIACLE_266 which is the (correct) form when the monitor doesn't return anything ($PROFILEMONITOR is null).

Anyway, it causes the system to never get into X windows, as when the /usr/X11R7/bin/xlogin script checks to see if the hardware has changed, it always thinks it has, and runs xorgwizard again. And again, forever.

I'm going to look for a way to get xlogin to accept/use a file matching what I have, ie. with no monitor id string in its name, when $PROFILEMONITOR is a null variable. That could fix the problem.
It could also help those running monitor-less systems.
I'll be getting going on that when I come back from a few days away. In the meantime, if anyone has any thoughts... post here.


eagles-lair 07-11-2007 07:24 AM

Simon, have you tried copying and pasting lines from the /etc/X11/xorg.conf file (whatever the path is, lol) on another working installation into the grafpup installation (or live)?

I initially did things like that in the early versions of PC-BSD because of difficulties in configuring any resolution apart from 1024x768 in its pre-version1.0 release days.

South Australia

emlsnws 07-12-2007 11:58 AM


No I haven't tried that, don't need to really, but thanks for the suggestion.

I've progressed a little on this: I determined that my monitor does have DDC info (not ddi, that was a typo) and the ID is correctly obtained "most of the time".

For some reason, the monitor didn't return it during the incident that led to me starting this thread.

What I have done, is added some lines to the 'xlogin' script, to detect the lack of monitor (either because it really is unplugged, or it's there but unresponsive to a ddcprobe) and set a flag. This lets me know whether to ignore the (null) $PROFILEMONITOR shell variable which occurs in that case.

I don't quite know where to go with this bit of code next, but my idea is that I could find and use an xorg.conf, taken from *any* previously-used one on the system, with the matching video chipset.
That would work in the event the monitor is unplugged or no DDC info is returned, and get X started - with 'some kind of' display parameters.

I need X to start, because I'm going to use x11vnc for remote desktop access. That uses the 'main desktop', not extra ones separate from the main, like some other VNC programs do (TightVNC etc). I also found that running a second X server (TightVNC) was costly to my system speed (it's only a medium power machine).

I also had trouble getting logins to function on tightvnc type programs, since Slim only permits one instance running at a time. That was a whole load of problems I didn't fancy addressing, so I've gone for the alternative path of using the main desktop over VNC. It lets me work on the machine if I'm at the console, or elsewhere on my network. Quite in line with the Puppy concept I think, simple and lean, but effective.

emlsnws 07-13-2007 12:23 PM

Oh, I forgot to mention.

In working out what was going on with the xlogin script, I found that it had fallen foul of a problem that's occurred before....

I think it was lines 265 and 304 of xlogin, the variable $HOME is referred to - but when xlogin is run from /etc/inittab that variable is not defined. So, I was seeing error messages like:

//.config/XLOADED : not found

Nathan has seen this elsewhere and it's an easy fix. I put this:


at the top of the file, which fixed it just fine.

All times are GMT -5. The time now is 07:48 PM.