Bug#643763: dexconf fails due to missing xserver-xorg/config/device/bus_id

[Edward Welbourne <eddy@opera.com>]

Hi again Julien,

and thanks for your assistance.

> Section "Monitor"
>         Identifier "<fill in randr output name here>"
>         Option "Rotate" "left"
> EndSection

I take it you mean an xorg.conf containing *only* this section will
suffice; any content in xorg.conf will be merged to what would have
been used without it.

I'm not clear on what "<fill in randr output name here>" entails.
I have no command named randr.  I have one named xrandr; and its man
page talks about outputs, but it appears to expect me to know the name
of the output already.  How do I query the system to obtain the
relevant name ?  I would previously have found that by looking at the
name dexconf wrote into the xorg.conf file I can't get it to generate ...

When I run xrandr with no args, it reports: <quote>

Screen 0: minimum 320 x 200, current 1600 x 1200, maximum 8192 x 8192
DVI-0 unknown connection (normal left inverted right x axis y axis)
   1360x768       59.8
   1152x864       60.0
   1024x768       60.0
   800x600        60.3
   640x480        59.9
DVI-1 connected 1600x1200+0+0 (normal left inverted right x axis y axis) 367mm x 275mm
   1600x1200      60.0*+
   1280x1024      75.0     60.0
   1152x864       75.0
   1024x768       75.1     60.0
   800x600        75.0     60.3
   640x480        75.0     60.0
   720x400        70.1

</quote>

Which part of that is the "output" name ?

Given that DVI-1 has *+ after one of its modes, I take it it's the one
that's actually connected to the running X session.  However, using
DVI-1 as the output name above and restarting xdm, I render the new
box unusable - xdm clearly shut down and tried to restart, but then
the screen went black and no longer responded to the keyboard -
fortunately, I can ssh into it to fix that.

(My attempts to start an X session are currently hampered by something
not liking the call to shopt in my ~/.bashrc and the uses of the
"function" built-in in ~/.bash_profile, even though whatever's having
the problem claims SHELL is /bin/bash - and, obviously, I can see no
reason why anything but bash would be reading these files anyway - but
I'll fight with that later.  I was able to get xrandr to run before
that hit ...)

	Eddy.