> Date: Tue, 31 Mar 2020 16:48:39 +0200 > From: Patrick Wildt <patr...@blueri.se> > Cc: Marcus MERIGHI <mcmer-open...@tor.at>, arm@openbsd.org, > kette...@openbsd.org > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > On Wed, Mar 25, 2020 at 01:15:03PM +0100, Otto Moerbeek wrote: > > On Wed, Mar 25, 2020 at 01:02:24PM +0100, Marcus MERIGHI wrote: > > > > > Hello, > > > > > > as I spend a lot of time with my Pinebook14/Pro there's things to report > > > and even more things to ask. > > > > > > Should I file bug reports to bugs@ or should it stay here (arm@)? > > > > > > Or is it to early wrt the Pinebook14/Pro and I should just enjoy what > > > works and live with the things that do not? > > > > > > The bug report would be: > > > > > > I've noted that the automatic start of xenodm(1) via rc.d(8) fails. > > > Xorg.0.log and dmesg attached below. > > > > > > If I do "rcctl start xenodm" later, xenodm(1) and X(7) work. > > > > his is known and has to do with the keyboard-trackpad interaction. > > IIRC patrick was already planning tol solve this. > > > > -Otto > > > > I dug deep and it turns out that it's not the hardware! X seems to > initially try to open the wrong device, and only after getty spawned > on /dev/ttyC1, it will try /dev/ttyC4 and succeed. > > Apparently kettenis@ wrote that code, so he might have an idea on how > to proceed on that issue.
I didn't write *that* code. Just the code that figures out which /dev/tty[C-J]0 is the actual console corresponding to /dev/console. What seems to be happening here is that xenodm(1) and getty(8) are racing eachother. Xorg looks for a free VT, chooses /dev/ttyC1 but after it actually opens that VT, getty(8) is already running on it and blocks us from switching into raw mode?
