From owner-freebsd-current@freebsd.org Wed Dec 2 07:00:15 2020 Return-Path: Delivered-To: freebsd-current@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 613AD4724A6 for ; Wed, 2 Dec 2020 07:00:15 +0000 (UTC) (envelope-from ali.abdallah@suse.com) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp2.suse.de", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Cm8xC1nB1z4SWx; Wed, 2 Dec 2020 07:00:15 +0000 (UTC) (envelope-from ali.abdallah@suse.com) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id B31B0ABD2; Wed, 2 Dec 2020 07:00:12 +0000 (UTC) Date: Wed, 2 Dec 2020 08:00:11 +0100 From: Ali Abdallah To: Scott Long Cc: myfreeweb , freebsd-current@freebsd.org, Hans Petter Selasky , Scott Long Subject: Re: Issues with USB-C external monitors Message-ID: <20201202070011.amdv7hxpq52x7zjw@frix230> References: <20201201131430.ol7pzms24h743iwf@frix230> <342519ee-6f73-98be-29b1-cea7890ccb1e@selasky.org> <20201201173223.mwmrkogcjmtc4k2j@frix230> <68205920-BE4F-460D-BF70-1A84FE3BC536@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <68205920-BE4F-460D-BF70-1A84FE3BC536@samsco.org> X-Rspamd-Queue-Id: 4Cm8xC1nB1z4SWx X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2020 07:00:15 -0000 On 01.12.2020 11:08, Scott Long wrote: > I have a work-in-progress to support Thunderbolt, but that’s not always the same as just DisplayPort-over-USBC. If your connector has the Thunderbolt logo, then it’s Thunderbolt, if it has the DP logo then it’s not. Even then, the Thunderbolt component only controls enable/disable permissions and bandwidth partitioning. The graphics chip and DRM code does the rest of the work, and it sounds like the problems here are with those components. T495 has AMD Ryzen silicon, and AMD never associated Thunderbolt with its Ryzen platforms. The dock connector is just a USB-C. On dock removal, the devd events (system DRM, type HOTPLUG) are correctly generated and received by libudev-devd, but then for some reason UD_ACTION_HOTPLUG is not causing the X server to re-scan drm connectors and to re-configure them. Will dig further into the issue as I feel it should be easy to solve. > > Scott > Ali