Re: faq 11 can be clarified

[bian]

On 2015-11-14 19:58, bian wrote:

On 2015-11-14 17:22, Mike Burns wrote:

On 2015-11-14 16.27.30 +0100, bian wrote:

* clear up the links 
http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/xenocara/distrib/notes/README.amd64
and 
http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/xenocara/distrib/notes/README.i386
. The linked text refers to the page where the links are. This is not 
very
helpful as the user never would have clicked the link if the info 
already

was available. Furthermore, the linked text ends with the phrase
"problem_blurb" suggesting that it is unfinished.


Perhaps you have a patch that clarifies this?


No patch, but a short term improvement is to replace the text which
the above links point at with the text in /usr/X11R6/README included
in the 5.8 release.


Which is the following:

--- README.amd64Sun Nov 15 14:44:32 2015
+++ README.5.8  Sun Nov 15 14:45:10 2015
@@ -27,9 +27,9 @@ Conventions used in this document:

See also Xorg(1), xorg.conf(5).

-3. With X.Org XOrgVersion, you can use anti-aliased fonts in many 
applications.

+3. With X.Org 7.7, you can use anti-aliased fonts in many applications.
visit http://www.openbsd.org/faq/truetype.html for more information.

-problem_blurb
+

 $OpenBSD: README.amd64,v 1.8 2014/07/30 20:06:30 matthieu Exp $

Re: faq 11 can be clarified

[ropers]

On 15 November 2015 at 09:18, bian  wrote:

> On 2015-11-14 17:22, Mike Burns wrote:
>
> I believe Xorg -configure has been useless for a long time.
>> With a hardware that just works, X just works. If a xorg.conf is needed
>> (as when e.g. using vesa instead of a misbehaving driver),
>> it is easier to write a simple one from xorg.conf(5) by hand.
>>
>> Jan
>>
>
> This is one way of looking at it, yes. However, the quality of the
> produced xorg.conf.new is fine.
>

I realise these are relatively rare cases for maybe somewhat exotic needs,
but there are legitimate reasons why you might want to use Xorg -configure.

tl;dr: Just because you can autodetect once (i.e. "X just works") doesn't
mean you can autodetect every time.

Suppose your video output is connected using a VGA connector (not
necessarily one still on your graphics card, maybe just in the form of a
DVI to VGA adapter somewhere along the line), and suppose your VGA cabling
does not connect the I²C  / DDC <
https://en.wikipedia.org/wiki/Display_Data_Channel> pins.
Why might those pins not be connected?
First, not all 15-pin VGA cables are equal (and there even were very early
cables with a DE-9M on at least one end instead of DE-15M D-subs on both
ends, cf. ).
Second, someone might be using this kind of a balun <
http://www.dx.com/p/utp8201ar-300-single-channel-twisted-pair-vga-video-balun
-receiver-black-184382>
or any number of similar devices, which only connect 8 pins, because the
VGA signal is carried (balanced, but still carried) over existing Cat
5/6/whatever twisted pair with 8P8C/RJ45 connectors (count the shielding if
fully connected and you might say that's 9 pins).

Without the Display Data Channel, monitor/resolution/etc. autodetection
will not work.

You might still wish to rely on autodetection for initial setup, when you
would have a compatible monitor directly connected WITH DDC. Xorg
-configure would write you a nice xorg.conf.
Afterwards, in regular use, your monitor would be connected WITHOUT DDC,
preventing any sensing/plug and play/autodetection from working.

Don't assume that just because you can do X once, you'll always be able to
do X ('scuse the pun).

regards,
–ropers

Re: faq 11 can be clarified

[bian]

On 2015-11-14 17:22, Mike Burns wrote:

On 2015-11-14 16.27.30 +0100, bian wrote:

* mention that the "segmentation fault"-message when running the X
-configure is harmless and that the xorg.conf.new file was created as 
it

should.


That's a bug, and while I likely can't fix it (will gladly look), 
we'll

need your dmesg and the backtrace from the coredump, in the least.



I believe Xorg -configure has been useless for a long time.
With a hardware that just works, X just works. If a xorg.conf is needed
(as when e.g. using vesa instead of a misbehaving driver),
it is easier to write a simple one from xorg.conf(5) by hand.

Jan


This is one way of looking at it, yes. However, the quality of the 
produced xorg.conf.new is fine.


/Birger

Re: faq 11 can be clarified

[Jan Stary]

On Nov 14 17:22:23, mike+open...@mike-burns.com wrote:
> On 2015-11-14 16.27.30 +0100, bian wrote:
> > * mention that the "segmentation fault"-message when running the X
> > -configure is harmless and that the xorg.conf.new file was created as it
> > should.
> 
> That's a bug, and while I likely can't fix it (will gladly look), we'll
> need your dmesg and the backtrace from the coredump, in the least.

I believe Xorg -configure has been useless for a long time.
With a hardware that just works, X just works. If a xorg.conf is needed
(as when e.g. using vesa instead of a misbehaving driver),
it is easier to write a simple one from xorg.conf(5) by hand.

Jan



> > * be sure that this info is obvious: "Your xorg.conf file is
> > /root/xorg.conf.new ". A new user typically logs in to his account, su to
> > root, run X -configure, and start looking for the file in the current
> > directory. Well, it's not there.
> 
> Seems like something that should be updated in Xorg(1). Though, I must
> say: typically a new user will not configure X at all, and won't use
> su(1) if they do. Does this confusion appear when using doas(1)/sudo(1)?
> 
> > * clear up the links 
> > http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/xenocara/distrib/notes/README.amd64
> > and 
> > http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/xenocara/distrib/notes/README.i386
> > . The linked text refers to the page where the links are. This is not very
> > helpful as the user never would have clicked the link if the info already
> > was available. Furthermore, the linked text ends with the phrase
> > "problem_blurb" suggesting that it is unfinished.
> 
> Perhaps you have a patch that clarifies this?

Re: faq 11 can be clarified

[bian]

On 2015-11-14 17:22, Mike Burns wrote:

On 2015-11-14 16.27.30 +0100, bian wrote:

* mention that the "segmentation fault"-message when running the X
-configure is harmless and that the xorg.conf.new file was created as 
it

should.


That's a bug, and while I likely can't fix it (will gladly look), we'll
need your dmesg and the backtrace from the coredump, in the least.


I will post this shortly in the bugs list on your suggestion.




* be sure that this info is obvious: "Your xorg.conf file is
/root/xorg.conf.new ". A new user typically logs in to his account, su 
to

root, run X -configure, and start looking for the file in the current
directory. Well, it's not there.


Seems like something that should be updated in Xorg(1). Though, I must
say: typically a new user will not configure X at all,


true, but how can faq 11 help if he must (or want).


and won't use su(1) if they do.
Does this confusion appear when using doas(1)/sudo(1)?


Yes. Running sudo X -configure will create the file in /root as 
expected. This way of working does not improve on the situation.




* clear up the links 
http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/xenocara/distrib/notes/README.amd64
and 
http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/xenocara/distrib/notes/README.i386
. The linked text refers to the page where the links are. This is not 
very
helpful as the user never would have clicked the link if the info 
already

was available. Furthermore, the linked text ends with the phrase
"problem_blurb" suggesting that it is unfinished.


Perhaps you have a patch that clarifies this?


No patch, but a short term improvement is to replace the text which the 
above links point at with the text in /usr/X11R6/README included in the 
5.8 release.


Generally about faq 11, there was a promising discussion on quality 
issues in http://marc.info/?l=openbsd-www&m=139222057820465&w=2 but it 
seems to have fizzled out unfortunately.

Re: faq 11 can be clarified

[Mike Burns]

On 2015-11-14 16.27.30 +0100, bian wrote:
> * mention that the "segmentation fault"-message when running the X
> -configure is harmless and that the xorg.conf.new file was created as it
> should.

That's a bug, and while I likely can't fix it (will gladly look), we'll
need your dmesg and the backtrace from the coredump, in the least.

> * be sure that this info is obvious: "Your xorg.conf file is
> /root/xorg.conf.new ". A new user typically logs in to his account, su to
> root, run X -configure, and start looking for the file in the current
> directory. Well, it's not there.

Seems like something that should be updated in Xorg(1). Though, I must
say: typically a new user will not configure X at all, and won't use
su(1) if they do. Does this confusion appear when using doas(1)/sudo(1)?

> * clear up the links 
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/xenocara/distrib/notes/README.amd64
> and 
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/xenocara/distrib/notes/README.i386
> . The linked text refers to the page where the links are. This is not very
> helpful as the user never would have clicked the link if the info already
> was available. Furthermore, the linked text ends with the phrase
> "problem_blurb" suggesting that it is unfinished.

Perhaps you have a patch that clarifies this?