grml-x fluxbox
How do I start the X server
Please use the command 'grml-x' as user 'grml' for starting X. It generates the config file /etc/X11/xorg.conf and lets you start commands on startup (see ~/.xinitrc). Use it, for example, via switching to TTY4 (press Alt+F4) and run the following command to start window manager fluxbox:
grml-x fluxbox
grml-x options
grml-x supports several options. If you want to set some special options please take a look at the grml-x manpage (man grml-x)! Some usage examples:
grml-x -display 8 fluxbox # start fluxbox on display 8 grml-x -force -nostart # force creation of xconfig file and don't start X server grml-x -hsync 60 fluxbox # set horizontal frequency and start fluxbox grml-x -hsync 60 -vsync 40 fluxbox # set horizontal and vertical sync frequencies and start fluxbox grml-x -mode '800x600' fluxbox # set resolution to 800x600 and start fluxbox grml-x -module vesa fluxbox # start fluxbox and use vesa module
resolution
Just run xrandr to switch the resolution. For example: 'xrandr -s 1024x768'.
xrandr -s 1152x864
Newsgroups: gmane.linux.distributions.grml.user Date: Fri, 4 Aug 2006 11:02:36 +0200
> > As far i understand the issue, your hardware doesn't support DDC, > > which is used to find out which sync rates your monitor uses. As a > > consequence X tries to guess some common frequencies, and obviously > > took the wrong ones. ;-)
> But, of course, it does - that is why I am perplexed.
> edid recognises it immediately - there are almost no monitors in current > use that do not support ddc, and the dell certainly does.
> Somewhere, some information is failing to go somewhere.
> So the question is why, when edid knows what the monitor is, and every > other distro I try certainly does, where the script is not pulling down > the id.
Well, grml-x currently does not use "get-edid | parse-edid" but uses just hwinfo and the mechanisms of X-server itself.
The main problem is: who can you trust? To give you an example how unreliable all the X-server stuff is take a look at my box:
# get-edid | parse-edid [...] The EDID data should not be trusted as the VBE call failed Error: output block unchanged parse-edid: IO error reading EDID
=> nothing I could use. So next step:
# hwinfo --monitor
30: None 00.0: 10000 Monitor
[Created at fb.70]
Unique ID: rdCR.EY_qmtb9YY0
Hardware Class: monitor
Model: "Generic Monitor"
Vendor: "Generic"
Device: "Monitor"
Resolution: 1024x768@76Hz
Driver Info #0:
Max. Resolution: 1024x768
Vert. Sync Range: 50-90 Hz
Hor. Sync Range: 31-61 kHz
Config Status: cfg=new, avail=yes, need=no, active=unknown
=> well, lying as well. See what I'm really using and what my laptop supports:
% xdpyinfo | grep dim dimensions: 1400x1050 pixels (356x267 millimeters)
So: I can't trust BIOS, nor edid, nor hwinfo. X guesses the possibilites at its best on my box (providing some basic information of course). But that's just one box out of several thousand different types of hardware combinations. And therefore grml-x does work better on some boxes than other X-configuration tools and sometimes not. The module causing most problems and headache is BTW radeon. And often it helps running something like "xrandr -s '1024x768'" as soon as X has been started (bound to ctrl-alt-d in fluxbox on grml BTW).
BTW: I'm planning to rewrite grml-x when grml 0.8 is out. All options should stay the same, but in the background I'll try to improve certain stuff. Especially because I'd like to provide (basic) dualhead-support with the new grml-x version.
-mika-
> > Well, grml-x currently does not use "get-edid | parse-edid" but uses > > just hwinfo and the mechanisms of X-server itself.
> > The main problem is: who can you trust? To give you an example how > > unreliable all the X-server stuff is take a look at my box:
> > # get-edid | parse-edid > > [...] > > The EDID data should not be trusted as the VBE call failed Error: > > output block unchanged > > parse-edid: IO error reading EDID
> May I suggest that if "get-edid | parse-edid" can return valid results, > use it as the first choice? I just run it and found that it is much > meaningful them my current xorg.conf result, which uses screen[0] and > device[0].
Yes, I will consider 'get-edid | parse-edid' for inclusion in the rewrite of grml-x.
> FYI, what is automatically detected from my system: [...]
Thanks.
-mika-
> However "startx" returns with an error informing me that the login is not > authorized to use the X srvr. I looked through some of the X related scripts > and have combed through some of the Debian docs and links the Knoppix has > set up, but to no avail.
Since Knoppix is based on Debian it is likely that it uses the Xwrapper program. This is controlled by /etc/X11/Xwrapper.config on a "sarge" version of Debian. This file contains the "allowed_users" option with possible values of "rootonly", "console" and "anybody".
For more details "man Xwrapper.config" is your best bet. Since this file can be managed by "debconf" you could also try to run
dpkg-reconfigure -plow xserver-common
but I am not sure how many changes Knoppix makes to "debconf"-style configuration.
AFAICT, the debconf style intact as one would expect it to be in Debian.
OK, there is an Xwrapper config on the system which contains only the following:
allowed_users=console nice_value=-10
I discover that if I change 'console' to 'anybody' then X runs. There is remains a caveat with the .Xauthority file, however. It gets written as an empty file, whether or not I'm allowed to run X.
In any event, I'd kinda prefer to use the security mechanism that they're implementing here and leave it set to 'console'. So it seems that the problem may lie with the system determining that I'm not running starts from the console.