From nobody Fri Nov 25 12:47:33 2022 X-Original-To: x11@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 4NJZQK5mk2z4hmjT for ; Fri, 25 Nov 2022 12:47:37 +0000 (UTC) (envelope-from saper@saper.info) Received: from q.saper.info (q.saper.info [IPv6:2605:2700:0:2:a800:ff:fec7:5c61]) (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 ECDSA (P-384) client-digest SHA384) (Client CN "q.saper.info", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NJZQJ55vJz3r1F for ; Fri, 25 Nov 2022 12:47:36 +0000 (UTC) (envelope-from saper@saper.info) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=saper.info header.s=Sep2014 header.b=H7jsbado; spf=none (mx1.freebsd.org: domain of saper@saper.info has no SPF policy when checking 2605:2700:0:2:a800:ff:fec7:5c61) smtp.mailfrom=saper@saper.info; dmarc=none Received: from q.saper.info (localhost [127.0.0.1]) by q.saper.info (8.16.1/8.16.1) with ESMTPS id 2APClYMb017747 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Fri, 25 Nov 2022 12:47:34 GMT (envelope-from saper@saper.info) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=saper.info; s=Sep2014; t=1669380454; bh=yWmdgwBDb5s5/dsmsZT/1CaMGSjh+bvAZN05XMgVipw=; h=Date:From:To:Subject; b=H7jsbadoSWeC0sIXUou0UZb8yTmbPAm04ih0aZywC9Lm2k6NAOdhYimdtyy75TLLL /o9LyRYqJdJbl2NbWgy9vL5m9VK64oS15Go7++NwpoGtjzi07I5sH7c560z8Pht6aR IiksEkGX9/Wro9NoZ650Ys8i2mod7SxnPfzhuci8= Received: from localhost (saper@localhost) by q.saper.info (8.16.1/8.16.1/Submit) with ESMTP id 2APClXvP017744 for ; Fri, 25 Nov 2022 12:47:34 GMT (envelope-from saper@saper.info) X-Authentication-Warning: q.saper.info: saper owned process doing -bs Date: Fri, 25 Nov 2022 12:47:33 +0000 From: Marcin Cieslak To: x11@FreeBSD.org Subject: Xorg server not to take virtual console at all? Message-ID: <4osqs13q-3736-o795-5p86-51s47os8ppsr@fncre.vasb> List-Id: X11 List-Archive: https://lists.freebsd.org/archives/freebsd-x11 List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-x11@freebsd.org X-BeenThere: freebsd-x11@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Spamd-Result: default: False [-2.30 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[saper.info:s=Sep2014]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[saper.info]; MLMMJ_DEST(0.00)[x11@FreeBSD.org]; R_SPF_NA(0.00)[no SPF record]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[saper.info:+]; RCVD_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:47066, ipnet:2605:2700::/32, country:US]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[x11@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; HAS_XAW(0.00)[]; RCVD_TLS_LAST(0.00)[] X-Rspamd-Queue-Id: 4NJZQJ55vJz3r1F X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N I'd like to do some single-stepping in ddb to debug the graphics driver and I was wondering if there is any way to start Xorg server without taking any virtual console at all? I am using this to tell nvidia to use the external HDMI port only (DFP-0 would be internal LVDS connected display of a laptop ) Section "Device" Identifier "NvidiaRelaxed" Driver "nvidia" BusID "PCI:1:0:0" Option "ConnectedMonitor" "DFP-2" hw.vga.textmode=1 in /boot/loader.conf allows me to stay in the text mode upon boot. This gives me a blank ttyv on the laptop screen, but if I switch away from it via Ctrl-Alt-F1, external display gets blanked as well. I managed to get almost there by using: startx -- -ignoreABI -sharevts This way I can have a pure ttyv* to break into debugger and work there. But this has a major disadvantage that both share the input device (external USB keyboard) and whatever I type goes into both the X server and the ttyv screen. Typing Ctrl-C in the xterm can nuke the X server for example, I worked this around by switching to another ttyv away (not the one with the Xorg process). The more I think about it - maybe it is really more an input problem - "where should my keystrokes go and how do I switch" I'd like to set hardware watch on some data in ddb so the switch can be sudden and unexpected. Marcin