Hello, all.

I am installing FreeBSD 14.1 RELEASE onto my AC8 mini PC, and am stuck
like a fly in honey with configuring my display's native resolution for
X sessions. I successfully configured it for TTYs, by specifying the
following parmeters in /boot/loader.conf:

hw.i915kms.modeset=1
hw.vga.textmode=0
kern.vt.fb.default_mode="1680x1050"

and was hoping that this graphical mode would be inhertied for X, but it
is not, and X starts in 1024x768. `xrandr', however, lists the required resolution and lets me activate it by:

xrandr --output DP-2 --mode 1680x1050

My question is, how can I configure it as the default and only
resolution for X via corg.conf(5). I tried generating a config file
with

Xorg -configure

but if failed with:

[ 6812.450] _XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed
[ 6812.451] _XSERVTransMakeAllCOTSServerListeners: server already running
[ 6812.451] (EE)
Fatal server error:
[ 6812.451] (EE) Cannot establish any listening sockets - Make sure an X server isn't already running(EE)

Looks like I have to stop an existing instance of the Xorg server,
but I have no service or daemon with this name, and no X session
is is running.

I also tried to write the config by hand:

Section "Screen" Identifier "Main"
Device "AC8"
Monitor "Samsung"
EndSection

Section "Device"
Identifier "AC8"
Driver ??
EndSection

Section "Monitor"
Identifier "Samsung"
Mode ??
ModeLine ??
EndSection

As I understand, I have to specify a Mode /or/ ModeLine parameter in the "Monitor" section, but I can't find a working value for either. `man xorg.conf' mentions "VESA standard modes" in the description of both the parameters, but cannot find a way to specify them. Where are the names
and/or identifiers of the VESA modes documented, how do I specify such a
mode in xorg.conf?

I have also tried to generate a modeline with:

cvt 1680x1050

which gave me:

"1680x1050_60.00" 146.25 1680 1784 1960 2240 1050 1053 1059 1089 -hsync +vsync

Specifying this value for the Modeline parameter in xorg.conf, however,
has no effect: X starts in 1024x768, and I have invoke `xrandr' to set
the correct resolution. Perhaps, there should be a record in some log
file explaining why this Modeline was not applied, but I have not found
it.

Also, I don't know what value to assign to the Driver parameter in the
Device section, or how to make it use whatver driver is used to for my graphical virtual TTYs 1..8 . So far, I have no Driver entry at all.

I dislike trial-and-error approach and should appreciate your showing me
how to shoot all troubles methodically, by following the documentaiton
and without reliance on any personal expertise. I have the man pages,
but can seem to use them...
--- Synchronet 3.19b-Linux NewsLink 1.113

Anton Shepelev <ant@tilde.culb> wrote:

I also tried to write the config by hand:

Section "Screen" Identifier "Main"
Device "AC8"
Monitor "Samsung"
EndSection

Section "Device"
Identifier "AC8"
Driver ??
EndSection

Section "Monitor"
Identifier "Samsung"
Mode ??
ModeLine ??
EndSection

[...]

I have also tried to generate a modeline with:

cvt 1680x1050

which gave me:

"1680x1050_60.00" 146.25 1680 1784 1960 2240 1050 1053 1059 1089 -hsync +vsync

Specifying this value for the Modeline parameter in xorg.conf, however,
has no effect: X starts in 1024x768, and I have invoke `xrandr' to set
the correct resolution. Perhaps, there should be a record in some log
file explaining why this Modeline was not applied, but I have not found
it.

I have solved this one:

1. In the "Device" section,
link the output device with the Monitor section:
Option "Monitor-DP-2" "Samsung"

2. In the "Monitor" section,
set the specify the mode Modeline as the preferred one:
Option "PreferredMode" "1680x1050_60.00"
because otherwise the first supported mode is used, including the
built-in standard VESA modes.

But this solution is documented to work only with drivers supporting
RandR 1.2. Is there a more portable solution, i.e. one that works for
all drivers?
--- Synchronet 3.19b-Linux NewsLink 1.113

On Tue, 17 Sep 2024, Anton Shepelev wrote:

onto my AC8 mini PC

[...]

I dislike trial-and-error approach and should appreciate your showing me
how to shoot all troubles methodically

To be frank, the information you gave wasn't enough for troubleshooting methodically or otherwise. For example, you neither say what exact *brand*
(you seemed to give only the model) was this machine,
nor link to its technical documentation/datasheet.

The necessary information in this area includes:

- Mainboard's (or computer's)
- Brand
- Model
- Link to datasheet
- Video card's...
- Brand
- Model
- Chipset's
- brand
- number
- Interfacing method (on-board, PCI, AGP, PCIe, USB)
- Output ports (how many, and what each of it was: RCA, Y/C, VGA,
DVI, LVDS, HDMI, DP, eDP, etc)
- Location of output (built-in screen, external, or both)
- Monitor's...
- Brand
- Model
- Display technology (CRT, LCD, OLED, etc)
- Interfacing method (RCA, Y/C, VGA, DVI, LVDS, HDMI, DP, eDP, etc)
- Sync frequency range (both horizontal and vertical)
- Native resolution and refresh rate (if any)
- Modelines documented in the owner's manual

Without these, readers wouldn't really have clue what you're asking about?
And I wouldn't have a clue either, had my laptop not been happening to sport
a similar line of on-board Intel Graphics chips as well [1].
(According to "i915"-- the only clue in your post)

With that out if the way...

On Tue, 17 Sep 2024, Anton Shepelev wrote:

showing me how to shoot all troubles methodically

Before I go bugging you about other details, I will give you a protip
of how to solve this problem *automatically* first:

1. Make sure that you terminate all instances of `X` and `Xorg`.
1. Back up your `xorg.conf`.
2. Run `Xorg -configure` as root.
3. Stop the Xorg server by pressing Ctrl+Alt+Backspace
if it hadn't terminated automatically.
4. Run the Xorg server in your "usual" way (`startx` or something like that).

If things goes "according to the plan", [2] it should start with
your monitor's native resolution by the time you finished step 4.

On Wed, 18 Sep 2024, Anton Shepelev wrote:

this solution is documented to work only with drivers supporting RandR 1.2.

Drivers supporting XRandR 1.2 *are* the norm, really.
From what I understand, using a driver that doesn't support XRandR
means you practically timetraveled back to the age when you ought
to operate X11 server at a fixed resolution in each Screen,
for the entire graphics session.

On Tue, 17 Sep 2024, Anton Shepelev wrote:

showing me how to shoot all troubles methodically,
by following the documentaiton
and without reliance on any personal expertise.

Unfortunately, there are often undocumented quirks on how these drivers operate; so you cannot really exclude "personal expertise"
out of the equation if you would really like these problems solved.

Regarding the so-called `i915` video device, there are actually
multiple Xorg drivers [not to be confused with kernel modesetting drivers]
that could display on it (`intel` [3], `modesetting` [4], and `vesa` [5]
comes to mind).

Since it seems that you weren't sure what driver it was using to begin with;
I would still suggest that you also try the automagic process above,
and check the `xorg.conf` it generated to see that what driver it actually picked up to use with this card. (Even that you end up switching back
to your own backed-up `xorg.conf` file at the end)

Once you know what driver it actually use, you can now start looking
at the correct documentation for more-specific stuff. [3][4][5]

On Tue, 17 Sep 2024, Anton Shepelev wrote:

Specifying this value for the Modeline parameter in xorg.conf, however,
has no effect

Yeah, some driver (like `intel`) has "quirks" that it prefers [6] the list
of resolutions detected from the monitor over the one you explicitly spelled
in the `xorg.conf` file. (And no, setting `Option "DDC" "off"`
is ignored in my experience)

And when it does this, you're often at the mercy of your monitor to actually give out the correct and complete EDID [7] information; including "trivia"
like the preferred/native modeline.

If that information was't complete or was wrong
(this happens on more screens that you'd think), then it would explain
why Xorg recognized that resolution, but wouldn't start up
at that resolution until you actually added
the "preferred mode" information on top of it.

(If you started up Xorg *without* "PreferredMode" in your "Monitor" section
of `xorg.conf`; and run `xrandr --verbose`, then look for "+preferred"
in the output, it would give you some clue if the monitor
was providing this trivia correctly, or at all)

Regards,
~xwindows
(Just a GNU/Linux user)

-----

[1] My laptop has Intel HD 4000 built-in graphics card, which comes
with Intel Core i5-3230M CPU. Its graphics is also handled
in Kernel Linux's level by a driver called "i915".

[2] Things rarely went 100% to the plan in reality, but you get the idea.

[3] `man intel`

[4] `man modesetting`

[5] `man vesa`

[6] I think it virtually prepended the list of modelines it detected
to the position *before* the first one you explicitly written
in the Monitor section; but don't quote me on this, I haven't RTFS'd.

[7] Extended Display Identification Data, which is data communicated
on VESA DDC protocol (via I^2C pins exist on VGA, DVI,
and HDMI connector) as soon as you plug the display into your computer.
It gives information about modelines supported by the monitor,
as well as miscellany like physical dimension.
--
xwindows' gallery of freely-licensed artworks
https://tilde.club/~xwindows/ http://tilde.club/~xwindows/ gopher://tilde.club/1/~xwindows/
--- Synchronet 3.19b-Linux NewsLink 1.113

xwindows <xwindows@tilde.club> wrote:

On Tue, 17 Sep 2024, Anton Shepelev wrote:

onto my AC8 mini PC

[...]

I dislike trial-and-error approach and should appreciate your showing me
how to shoot all troubles methodically

To be frank, the information you gave wasn't enough for troubleshooting >methodically or otherwise. For example, you neither say what exact *brand* >(you seemed to give only the model) was this machine,
nor link to its technical documentation/datasheet.

The necessary information in this area includes:

- Mainboard's (or computer's)
- Brand
- Model
- Link to datasheet
- Video card's...
- Brand
- Model
- Chipset's
- brand
- number
- Interfacing method (on-board, PCI, AGP, PCIe, USB)
- Output ports (how many, and what each of it was: RCA, Y/C, VGA,
DVI, LVDS, HDMI, DP, eDP, etc)
- Location of output (built-in screen, external, or both)
- Monitor's...
- Brand
- Model
- Display technology (CRT, LCD, OLED, etc)
- Interfacing method (RCA, Y/C, VGA, DVI, LVDS, HDMI, DP, eDP, etc)
- Sync frequency range (both horizontal and vertical)
- Native resolution and refresh rate (if any)
- Modelines documented in the owner's manual

Without these, readers wouldn't really have clue what you're asking about?

My idea of /methodical/ implies learing from the basics, which in
this case is the diagnostics, logging, and configuration tools
provided by the OS for setting up X; and only after one has learned
somewhat of /the lay of the land/ can one start exploring its nooks
and crannies, weeding, planting tentatively, &c.

Well then -- this PC of mine is Newsmay AC8:
(the Chinese are apt at inventing cheap English names)

<http://www.newsmaytech.com/product/showproduct.php?lang=en&id=74>

and here are its specs as gathered by hw-probe:

<https://bsd-hardware.info/?probe=170341d296>

Before I go bugging you about other details, I will give you a protip
of how to solve this problem *automatically* first:

1. Make sure that you terminate all instances of `X` and `Xorg`.
1. Back up your `xorg.conf`.
2. Run `Xorg -configure` as root.
3. Stop the Xorg server by pressing Ctrl+Alt+Backspace
if it hadn't terminated automatically.
4. Run the Xorg server in your "usual" way (`startx` or something like that).

This was one of the first recommendations that I found in the
internet (wheresoever that may be), but the generated xorg.conf
file did not help, and no wonder: it is generated by the same
algorithm of automatic configuration that is used when Xorg starts
wihout a configuration file. Yes, theoretically it should work
right out-of-the-box with no config at all (craeted manually or
otherwise), but with some quircky hardware it may not... Since there
are several possible locations for xorg.conf, I made a point of
bungling the file and causing Xorg to fail with a parse error.

At first I had suspected by monitor (Samsung SyncMastr T200) for
failing to provide correct EDID information over the VGA cable, but
then I learned that /some/ Linuxes (e.g. Debian Dog) somehow pick
the correct resolution with no help of mine, and that the problem
is observed with other monitors, so it must be due to a combination
of OS and hardware.

The generated config is here:

<https://freeshell.de/~antonius/file_host/xorg.conf.new>

Xorg gave if the `.new' postfix, but of course I removed it for
testing.

If things goes "according to the plan", [2] it should start with
your monitor's native resolution by the time you finished step 4.

Is it not, "according to plan," if you forgive me this question
as thou shalt forgive the learners of thy tongue?

On Wed, 18 Sep 2024, Anton Shepelev wrote:

this solution is documented to work only with drivers supporting RandR 1.2.

Drivers supporting XRandR 1.2 *are* the norm, really.

Yes, for many years now. I was simly wondering what one is/was to
do with older drivers, but perhaps I ought not to worry about such
hypothetical situaitons, at least at this stage. Let us skip it.

From what I understand, using a driver that doesn't support XRandR
means you practically timetraveled back to the age when you ought
to operate X11 server at a fixed resolution in each Screen,
for the entire graphics session.

Which sounds like a perfectly normal situation for a home PC.

On Tue, 17 Sep 2024, Anton Shepelev wrote:

showing me how to shoot all troubles methodically,
by following the documentaiton
and without reliance on any personal expertise.

Unfortunately, there are often undocumented quirks on how these drivers >operate; so you cannot really exclude "personal expertise"
out of the equation if you would really like these problems solved.

It was an unfortunate expression on my part. I meant the kind of
random ad hoc advice to try this or that without the beneficiary
(and often the benefactor, eithe ) understanding why it may help, as
opposed to locating, or at least narrowing-down the problem in a
deductive manner.

Regarding the so-called `i915` video device, there are actually
multiple Xorg drivers [not to be confused with kernel modesetting drivers]

Yes, I do not understand this difference. Will read about KMS.

that could display on it (`intel` [3], `modesetting` [4], and `vesa` [5] >comes to mind).

The auto-generated xorg.conf has

Driver: "modesetting"

in the "Device" section, so we have found the driver used!

Since it seems that you weren't sure what driver it was using to begin with; >I would still suggest that you also try the automagic process above,
and check the `xorg.conf` it generated to see that what driver it actually >picked up to use with this card.

I anticipated you, see above :-)

(Even that you end up switching back
to your own backed-up `xorg.conf` file at the end)

I put my working configuration under

xort.conf.d/00-display.conf

which is the recommended
(loosely coupled, disctibuted, dependency-inverted)
way of storing Xorg configuration.

Once you know what driver it actually use, you can now start looking
at the correct documentation for more-specific stuff. [3][4][5]

Thanks, now I know where to read on. This "modesetting" driver is
documented as a framebuffer driver, and I didn't know X could work
over a framebuffer graphical interface. Should this "modesetting"
driver turn too generic to be efficient, I will look into ways of
using another one.

I want to setup graphical framebuffer TTYs to make them more
configurable, and to have basic graphics (e.g. a simple image viewer)
without X. By searching the internet I learned that this system
uses VT(4), but I have no idea how really to find it by examining
the system...

On Tue, 17 Sep 2024, Anton Shepelev wrote:

Specifying this value for the Modeline parameter in xorg.conf, however,
has no effect

Yeah, some driver (like `intel`) has "quirks" that it prefers [6] the list
of resolutions detected from the monitor over the one you explicitly spelled >in the `xorg.conf` file. (And no, setting `Option "DDC" "off"`
is ignored in my experience)

[6] I think it virtually prepended the list of modelines it detected
to the position *before* the first one you explicitly written
in the Monitor section; but don't quote me on this, I haven't RTFS'd.

All I have found in the docs is the the first listed mode
is activated in default of a preferred one. And yes, the
manually specified mode is appended to the list of "built-in"
ones, which in my case even contains clearly unsuppored
modes with too high a resolution.

And when it does this, you're often at the mercy of your monitor to actually >give out the correct and complete EDID [7] information; including "trivia" >like the preferred/native modeline.

If that information was't complete or was wrong
(this happens on more screens that you'd think), then it would explain
why Xorg recognized that resolution, but wouldn't start up
at that resolution until you actually added
the "preferred mode" information on top of it.

(If you started up Xorg *without* "PreferredMode" in your "Monitor" section >of `xorg.conf`; and run `xrandr --verbose`, then look for "+preferred"
in the output, it would give you some clue if the monitor
was providing this trivia correctly, or at all)

It says it prefers to burn my eyes with 1024x768.

Regards,
~xwindows
(Just a GNU/Linux user)

FreeBSD shares a lot of software with Linux, including
many hardware drivers, which the developers perfer to
port to FreeBSD rather than to write from scratch.

Thank you very much for the help, ~xwindows !
--- Synchronet 3.19b-Linux NewsLink 1.113