From nobody Thu Jun 23 15:37:55 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 23950859043 for ; Thu, 23 Jun 2022 15:38:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LTPXZ5qqgz4rXK for ; Thu, 23 Jun 2022 15:38:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa2f.google.com with SMTP id 15so6397293vko.13 for ; Thu, 23 Jun 2022 08:38:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ckf9tQevqFFrAdlBRTL12RlFvNu7hyDVT3T0Ol44zGw=; b=r9nS8WwHTQfeLkrDdbwWe4fx6lEgjadgGdJ9RfT5fiWLc1xXQHCERSKObWJ0hqBZTK AUwR9XVwK3o0zfoYVyxz7rOxvV6dHHoMfalz/DudIH4eAg3pt80IznZTHQnwiZjMuvcR uXQAB2RK65phINBgGCGhO0lxarbNtRx5WFAJeiBuf5Papke+vhjEi9DR4yoXqgatd83k xIhzajCzDIYIItSr2c0VbfmgfgTc0YL5831zvCNP1rkq7sAyA0W5O4YT1dF28wV8h29K iLXKnikEhuQ2nuMx6e03BNqa6PaPpd/sptHw8CWnB42nDVM/KTL/Jz6RgRFgv+mgMgSl W1SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ckf9tQevqFFrAdlBRTL12RlFvNu7hyDVT3T0Ol44zGw=; b=VrJ6XBX8C+9dEiUdrrBRgJ6bYm14S1wxC8KD6AGZsDHT6FNnXcKS7fvHGbORV5T6HT iGZ1ZwoGmTj5btwjfXnLsldOeleqFkmL17w4akV0T78gxsrSX9R7uPGSvpRV47sGw5jo /8S1nXxL6cLWfmM3Tk+SUaqZOjiqgsRYHlpsBEBQocUY/34C5XyUtV6pDdXjSg7AYjpY K1bGXZtSVwueo0VomPwheJaXbpEFZ2dKKncJYLg3fw9TePYidyoFFGrCwyGwaj1KyZbK 9lprhhHoZ1WOqoFXxaiY2Y5jv+mku6/L9F45kVqwETL2/iw5Yxdl+W7DOQAdhhArxo4N Y4aw== X-Gm-Message-State: AJIora98blQv/rS4Ihx6Eo8Q4l+aKLI8qRWRW7Z0/bP1Ldy+3OcR67sa 01Fe2hOrWwxRrWktUAFjLBBQl8wRUxte4kvweIAPdPgPe8A= X-Google-Smtp-Source: AGRyM1tpANkfa7xQZ1k+WEDQ7aRJjCDjyy4/kQYqrp7e1HWkqH2cXBsNq1wS5tABbKfc99wf0UjRHlA7BaMZmi78dTk= X-Received: by 2002:a05:6122:10d6:b0:36c:17a4:28b with SMTP id l22-20020a05612210d600b0036c17a4028bmr10963446vko.23.1655998686182; Thu, 23 Jun 2022 08:38:06 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> In-Reply-To: From: Warner Losh Date: Thu, 23 Jun 2022 09:37:55 -0600 Message-ID: Subject: Re: Reasons for keeping sc(4) and libvgl ? To: Cejka Rudolf Cc: Emmanuel Vadot , FreeBSD Hackers Content-Type: multipart/alternative; boundary="00000000000070543505e21f3d4d" X-Rspamd-Queue-Id: 4LTPXZ5qqgz4rXK X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=r9nS8WwH; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::a2f) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-1.89 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.91)[-0.907]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-0.99)[-0.985]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; NEURAL_HAM_SHORT(-1.00)[-0.999]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a2f:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --00000000000070543505e21f3d4d Content-Type: text/plain; charset="UTF-8" On Thu, Jun 23, 2022 at 1:44 AM Cejka Rudolf wrote: > Hello, > so is there any solution for problem below now? > > Cejka Rudolf wrote (2021/11/29): > > Hello, > > I have one problem or two with VT in FreeBSD 12. I wrote a question in > > freebsd-stable what to do, but without response, so I still have to > > use SC. Please, could you look at it? There is not configured device > > /dev/console without monitor after upgrade from 11 to 12 and device > > /dev/kbdmux0 is busy using VT but not with SC. > > > > Subject: Unable to grab keyboard with VT on a headless node in stable/12 > > > > Hello, > > I have a headless node without monitor and without keyboard. There > > is just network and USB card reader in keyboard mode. > > > > In stable/11, there was no problem to disconnect USB card reader > > from kbdmux using kbdcontrol -A ukbd0 < /dev/console and open > > /dev/ukbd0 in a program. > > > > However, under stable/12 it works just with connected monitor. > > > > Without monitor, there is an error: > > > > # kbdcontrol < /dev/console > > -bash: /dev/console: Device not configured > > > > Furthermore with default VT, it is also impossible to use /dev/kbdmux0: > > > > # kbdcontrol < /dev/kbdmux0 > > -bash: /dev/kbdmux0: Device busy > > > > I have found a workaround using SC, where it is possible to atleast > > open /dev/kbdmux0 and use kbdcontrol -A ukbd0 < /dev/kbdmux0, but why > > keyboard operation is now dependend on connected monitor? And why VT > > does not allow to open /dev/kbdmux0? > > > > Thank you. > Have you filed a bug for this? This looks like a legit bug and one that should be easy(ish) to reproduce. Or at least it looks that way on the surface, there might be a pilot error as well that just happened to work before and needs a slightly different workaround to what you are doing... And it's an actual monitor connected that's the only difference? Or is this some KVM switch that's connected, so there's an atkbd in the mix somewhere? What's the difference in dmesg between these two boots? Is this with EFI or legacy BIOS boot? 'Not conifgured' is ENXIO which is returned when /dev/console isn't there (eg, no /dev/console), which seems weird in the extreme. And it's 'bash' that's giving the message, which means kbdcontrol isn't even getting invoked. A dmesg with bootverbose would be most enligtening. And I'm also a little confused, detach ukbd0 from a usb card reader? That's an interesting setup. While it won't affect whether or not this is a bug, I'd be interested to know more details there... Warner --00000000000070543505e21f3d4d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jun 23, 2022 at 1:44 AM Cejka= Rudolf <cejkar@fit.vutbr.cz&= gt; wrote:
Hello= ,
=C2=A0 so is there any solution for problem below now?

Cejka Rudolf wrote (2021/11/29):
> Hello,
>=C2=A0 =C2=A0I have one problem or two with VT in FreeBSD 12. I wrote a= question in
> freebsd-stable what to do, but without response, so I still have to > use SC. Please, could you look at it? There is not configured device > /dev/console without monitor after upgrade from 11 to 12 and device > /dev/kbdmux0 is busy using VT but not with SC.
>
> Subject: Unable to grab keyboard with VT on a headless node in stable/= 12
>
> Hello,
>=C2=A0 =C2=A0I have a headless node without monitor and without keyboar= d. There
> is just network and USB card reader in keyboard mode.
>
> In stable/11, there was no problem to disconnect USB card reader
> from kbdmux using kbdcontrol -A ukbd0 < /dev/console and open
> /dev/ukbd0 in a program.
>
> However, under stable/12 it works just with connected monitor.
>
> Without monitor, there is an error:
>
> # kbdcontrol < /dev/console
> -bash: /dev/console: Device not configured
>
> Furthermore with default VT, it is also impossible to use /dev/kbdmux0= :
>
> # kbdcontrol < /dev/kbdmux0
> -bash: /dev/kbdmux0: Device busy
>
> I have found a workaround using SC, where it is possible to atleast > open /dev/kbdmux0 and use kbdcontrol -A ukbd0 < /dev/kbdmux0, but w= hy
> keyboard operation is now dependend on connected monitor? And why VT > does not allow to open /dev/kbdmux0?
>
> Thank you.

Have you filed a bug fo= r this? This looks like a legit bug and one that should be easy(ish) to rep= roduce.
Or at least it looks that way on the surface, there might= be a pilot error as well that just happened to
work before and n= eeds a slightly different workaround to what you are doing...
And it's an actual monitor connected that's the only di= fference? Or is this some KVM switch that's
connected, so the= re's an atkbd in the mix somewhere? What's the difference in dmesg = between
these two boots? Is this with EFI or legacy BIOS boot?

'Not conifgured' is ENXIO which is returned = when /dev/console isn't there (eg, no /dev/console), which
se= ems weird in the extreme. And it's 'bash' that's giving the= message, which means kbdcontrol isn't
even getting invoked. = A dmesg with bootverbose=C2=A0would be most enligtening.

And I'm also a little confused, detach ukbd0 from a usb card rea= der? That's an interesting setup. While
it won't affect w= hether or not this is a bug, I'd be interested to know more details the= re...

Warner

--00000000000070543505e21f3d4d--