GrafpupThis forum is for the discussion of Grafpup Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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.
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.