From owner-freebsd-x11@freebsd.org Sun Nov 15 02:38:09 2020 Return-Path: Delivered-To: freebsd-x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 249C546F850 for ; Sun, 15 Nov 2020 02:38:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4CYbwd0LZDz4lmv for ; Sun, 15 Nov 2020 02:38:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 0BD7346F84F; Sun, 15 Nov 2020 02:38:09 +0000 (UTC) Delivered-To: x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0BA2946F84E for ; Sun, 15 Nov 2020 02:38:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CYbwc6rvXz4lhj for ; Sun, 15 Nov 2020 02:38:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id DEA71146F2 for ; Sun, 15 Nov 2020 02:38:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 0AF2c8gS010428 for ; Sun, 15 Nov 2020 02:38:08 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 0AF2c8ZK010427 for x11@FreeBSD.org; Sun, 15 Nov 2020 02:38:08 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: x11@FreeBSD.org Subject: [Bug 250826] x11/xorg incorrect autogenerated xorg.conf Date: Sun, 15 Nov 2020 02:38:09 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: billblake2018@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: x11@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2020 02:38:09 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D250826 --- Comment #5 from Bill Blake --- 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. :) Howe= ver, 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.=20 Here's what's going on. When ctwm starts, it translates the key names in i= ts 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 f= ile. My ctwm config uses Page_Up to invoke a menu and, without the i915kms driv= er, 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 ev= ents 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= .=20 Start ctwm. See my menu fail. Make ctwm restart via a menu option (invoke= d 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 ti= me, 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 fil= e 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. Ei= ther 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 disappear= ance when ctwm is restarted by a ctwm menu selection. --=20 You are receiving this mail because: You are the assignee for the bug.=