Bug 250826

Summary: x11/xorg incorrect autogenerated xorg.conf
Product: Ports & Packages Reporter: Bill Blake <billblake2018>
Component: Individual Port(s)Assignee: freebsd-x11 (Nobody) <x11>
Status: New ---    
Severity: Affects Only Me CC: zeising
Priority: --- Flags: bugzilla: maintainer-feedback? (x11)
Version: Latest   
Hardware: amd64   
OS: Any   
Description Flags
autogenerated configuration and log none

Description Bill Blake 2020-11-03 09:33:25 UTC
Created attachment 219320 [details]
autogenerated configuration and log

12.2-RELEASE, GENERIC kernel, stock X, Dell Latitude E6410.

I ran Xorg -configure to get a configuration.  X would not start with that configuration, muttering something about "open /dev/dri/card0: No such file or directory".  (Config and log attached. The log came from a different kernel, which has more VTs, but is essentially the same as the GENERIC log.)

I changed the Driver line in the Device section from "modesetting" to "vesa" and X started.  (It still didn't work properly, failing to handle my keyboard correctly.  I had to tell it to not auto-detect devices.  But that's for my next bug report.)
Comment 1 Niclas Zeising freebsd_committer 2020-11-03 15:20:00 UTC
There is generally no need to have a xorg configuration these days.

The error you are seeing is probably because the driver (drm-kmod) has not been loaded properly, so there is no graphics driver.  the vesa driver is using userland rendering.
Comment 2 Bill Blake 2020-11-03 18:59:03 UTC
X DOES NOT start on my machine when there is no X configuration.  (This is why I created a configuration in the first place.)

X DOES NOT start on my machine when the Xorg -configure output is used as a configuration, and it logs the same errors as X with no configuration.

X DOES start on my machine when I changed the Driver line in the autoconfiguration's Device section from "modesetting" to "vesa".

X DOES NOT start if I take the Device section out of the autoconfigure and it gives the same errors as when there is no X configuration.
Comment 3 Niclas Zeising freebsd_committer 2020-11-03 19:39:33 UTC
Have you loaded the graphics driver?
As I stated before, the error you are seeing (without the config) is most common when the GPU driver hasn't been loaded or attached to hardware.

Can you try building drm-fbsd12.0-kmod locally, and then add kld_load="/boot/modules/i915kms.ko" to /etc/rc.conf, remove the xorg conf and try again?
Comment 4 Bill Blake 2020-11-04 01:32:41 UTC
Loading i915kms into my kernel suffices to make X start and for X to get input from my keyboard.  I can use either the one from GENERIC or the one compiled from ports.


1)  This bug report is about the auto-generated xorg.conf.  X should have detected the fact that I didn't have i915kms and not generated an xorg.conf that relied on it.  I was able to tweak the auto-generated xorg.conf to make it work without i915kms, so X should have been able to do the same.  Alternately, in 5.4.4 and 5.4.8 of the Handbook, where it says one should not create a config unless X autoconfig fails, it should suggest loading i915kms (or another driver) before creating a config.

2) Using i915kms merely creates new problems for me.

First, a buglet: I happened to leave /etc/ttys as-is when I ran the GENERIC kernel and my normal /etc/ttys has a login on every tty that GENERIC allows, meaning that there were none for X.  X should have complained and died.  Instead, it took ttyv0 for itself, leading to amusing behavior as it contended with the shell for keyboard input.

And an annoyance: I use ctwm as my window manager and I bound ALT + Page Down and ALT + the arrow keys to various functions.  While my other ALT bindings (using letters) work fine, those ALT bindings do not work at all.  Presumably, X is sending different keys to ctwm when I'm using i915kms than it does when I'm not. I'm not thrilled by the idea of trying to track down what it is actually getting. 

And a deal-breaker: I am visually impaired and I have a nice big screen so that I can see what I'm doing.  At some point in the past, the vt driver decided to make the screen 100x37 instead of 80x25.  That was a pain, but I can still read it.  However, when I use i915kms, that 100x37 goes to 160x50 and I really can't read that without further damaging my back (because I have to lean way forward to read the screen).  There is no obvious way to change the screen size; vidcontrol doesn't seem to allow it.  (vidcontrol -i mode shows no modes; trying to change the size gets "Inappropriate ioctl for device".)  Since I use the text screens extensively, this alone makes i915kms useless for me.
Comment 5 Bill Blake 2020-11-15 02:38:09 UTC
OK, I took a day to play with things.  Here's the current status.

I am currently running *with* a config file, as described above.  Everything works fine, so I could theoretically just leave it as it is and wait until the next version of FreeBSD to see what breaks when I do that install. :)  However, I decided to try to fix things to work properly.  I didn't quite make it.

First, the font thing:  Putting a font8x16 into rc.conf let me go back to a 100x37 screen, but only for ttyv0.  I fixed that with some code in rc.local to do all the screens.  So at least I can read my text screens now!

Now, for ctwm.  I stuck some debugs into ctwm to track down the problem.  Here's what's going on.  When ctwm starts, it translates the key names in its config files to keysyms and then to keycodes, and records the action to be taken for particular keycodes.  Later, when a key is pressed, the keycode in the event is matched against the keycodes found when it parsed the config file.  My ctwm config uses Page_Up to invoke a menu and, without the i915kms driver, that becomes keysym ff55 and keycode 99.

When I use the i915kms driver, the keysyms and keycodes translated from the config file are apparently the same as without that driver.  *BUT* the X events have different keycodes!  For Page_Up the X event keycode is 112.  And, of course, that does not match what was recorded at initialization, which means that my menu doesn't work.

And now for the twist.  While tracking this down, I happen to notice that my key invoked menu magically started working!  Turns out I can reproduce this.  Start ctwm.  See my menu fail.  Make ctwm restart via a menu option (invoked by a click).  The second invocation gets the *new* keycodes at parse time and, since they match the X event codes, my menu then works.  Note that, for example, killing ctwm and restarting it doesn't work.  (In my .xinitrc, I started ctwm, slept 10 seconds, killed ctwm, slept some more and restarted ctwm.  Didn't fix the problem.)

To make this clear, XKeysymToKeycode returns different values at the two invocations of ctwm.  The first time, it returns 99 for ff55; the second time, it returns 112 for ff55.  The 99 is *not* what the X event structure returns when Page Up is pressed, 112 is.  Also, the 99 is what one gets from XKeysymToKeycode if the i915kms driver is *not* in use (and an X config file is present).

One other thing:  I had kinda hoped that just sleeping before the first invocation of ctwm would make the problem go away.  It didn't.  So it's not simply a matter of ctwm getting in before the server fully initialized.  Either ctwm is not doing some necessary initialization or something in the bowels of X or Xlib is broken.  I'm an X user, not an X programmer, so I wouldn't even know how to start looking, short of teaching myself X programming, which I don't have the time to do.

That said, if someone has some pointers as to where I might look, I'll give it a go.  The problem, as I said, is reproducible, as is its magical disappearance when ctwm is restarted by a ctwm menu selection.