Re: Issues with USB-C external monitors
Sorry for the noise, you can the patches at the following link: https://github.com/Alix82/FreeBSD-xorg-drm-hotplug On 03.12.2020 08:05, Ali Abdallah wrote: > On 02.12.2020 11:28, Ali Abdallah wrote: > > Actually Xorg on FreeBSD with UDEV is compiled with > > --disable-config-udev-kms, thus the server never calls: > > > > udev_monitor_filter_add_match_subsystem_devtype > > > > for GPU devices, and thus libudev-devd doesn't forward kms events to the > > server. Actually Xorg doesn't even process them, even if the filter check > > is bypassed in libudev-devd (udev-monitor.c:261). > > > > Basically Xorg is missing bsd platform code for drm devices, on Linux > > the code that implements that can be found in: > > hw/xfree86/os-support/linux/lnx_platform.c > > I'm attaching two patches that make hotpluggable drm connectors work on > FreeBSD with xorg-server compiled with UDEV. > > If you want to give them a try, for libudev-devd it is enough to apply > patch-libudev-devd-drm-hotplug.c, but for xorg-server you need to change > its Makefile to enable udev-kms, and apply > patch-xorg-server-drm-bsd-platform.c > > UDEV_CONFIGURE_ON= --disable-config-udev-kms > > to > > UDEV_CONFIGURE_ON= --enabled-config-udev-kms > > The bsd-platform code for the xorg-server is basically the same as Linux, > expect for the systemd bit obviously. For now, I appended the code to > hw/xfree86/os-support/bsd/bsd_VTsw.c just because I didn't want to patch > the Makefile.in or Makefile.am and fight with autotools. But that code > should finish in the future in bsd_platform.c. > > It is working perfectly fine for me, also got positive feedback from a > friend using it on a Thinkpad X280 with a USB-C dock. > > The patches even for onboard connectors deliver for "complete" desktop > plugging/unplugging external monitors events (such as Xfce, gnome, KDE), > and then the external monitors are configured automatically. > > I will also later on work on DEVD support as well. > > Regards. > > -- > Ali Abdallah | SUSE Linux L3 Engineer > GPG fingerprint: 51A0 F4A0 C8CF C98F 842E A9A8 B945 56F8 1C85 D0D5 > -- Ali Abdallah | SUSE Linux L3 Engineer GPG fingerprint: 51A0 F4A0 C8CF C98F 842E A9A8 B945 56F8 1C85 D0D5 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Issues with USB-C external monitors
On 02.12.2020 11:28, Ali Abdallah wrote: > Actually Xorg on FreeBSD with UDEV is compiled with > --disable-config-udev-kms, thus the server never calls: > > udev_monitor_filter_add_match_subsystem_devtype > > for GPU devices, and thus libudev-devd doesn't forward kms events to the > server. Actually Xorg doesn't even process them, even if the filter check > is bypassed in libudev-devd (udev-monitor.c:261). > > Basically Xorg is missing bsd platform code for drm devices, on Linux > the code that implements that can be found in: > hw/xfree86/os-support/linux/lnx_platform.c I'm attaching two patches that make hotpluggable drm connectors work on FreeBSD with xorg-server compiled with UDEV. If you want to give them a try, for libudev-devd it is enough to apply patch-libudev-devd-drm-hotplug.c, but for xorg-server you need to change its Makefile to enable udev-kms, and apply patch-xorg-server-drm-bsd-platform.c UDEV_CONFIGURE_ON= --disable-config-udev-kms to UDEV_CONFIGURE_ON= --enabled-config-udev-kms The bsd-platform code for the xorg-server is basically the same as Linux, expect for the systemd bit obviously. For now, I appended the code to hw/xfree86/os-support/bsd/bsd_VTsw.c just because I didn't want to patch the Makefile.in or Makefile.am and fight with autotools. But that code should finish in the future in bsd_platform.c. It is working perfectly fine for me, also got positive feedback from a friend using it on a Thinkpad X280 with a USB-C dock. The patches even for onboard connectors deliver for "complete" desktop plugging/unplugging external monitors events (such as Xfce, gnome, KDE), and then the external monitors are configured automatically. I will also later on work on DEVD support as well. Regards. -- Ali Abdallah | SUSE Linux L3 Engineer GPG fingerprint: 51A0 F4A0 C8CF C98F 842E A9A8 B945 56F8 1C85 D0D5 signature.asc Description: PGP signature
Re: Issues with USB-C external monitors
Ali Abdallah writes: > Sorry for the noise, you can the patches at the following link: > > https://github.com/Alix82/FreeBSD-xorg-drm-hotplug Thanks a lot Ali! With these patches my T480+TB3 dock works, with the following footnotes: I have disabled "TB3 Bios assist" in the BIOS and use a USB-C cable instead of the TB-3 cable, to keep TB3 out of this. At some point, probably years ago, I ran "make config" in x11-servers/xorg-server, and the state-file left in /var/db/ports kept UDEV disabled, despite the patch to Makefile in the bundle above. You can either remove the state-file or run "make config" again and select UDEV. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Issues with USB-C external monitors
On 01.12.2020 17:10, myfreeweb wrote: > devd (really drm in the kernel) provides hotplug events (system DRM, type > HOTPLUG). > libudev-devd translates these to UD_ACTION_HOTPLUG. > This works well with wlroots compositors at least. > How xorg does this I have no idea, as I don't use xorg. > If your xorg is built with DEVD instead of UDEV option, it shouldn't work, I > don't recall anyone adding support for that there. > With UDEV it might work? Actually Xorg on FreeBSD with UDEV is compiled with --disable-config-udev-kms, thus the server never calls: udev_monitor_filter_add_match_subsystem_devtype for GPU devices, and thus libudev-devd doesn't forward kms events to the server. Actually Xorg doesn't even process them, even if the filter check is bypassed in libudev-devd (udev-monitor.c:261). Basically Xorg is missing bsd platform code for drm devices, on Linux the code that implements that can be found in: hw/xfree86/os-support/linux/lnx_platform.c Compiling the server with --enable-config-udev-kms, the server expects to have the following functions implemented xf86PlatformReprobeDevice, xf86PlatformDeviceProbe, DeleteGPUDeviceRequest and xf86PlatformDeviceCheckBusID. Those are fairly easy to implement to enable Xorg to listen to libudev-devd drm events and to re-configure the drm connectors. I have already some scratch code, will test more and probably send upstream. I will probably also add devd code for that, as I use xorg server with devd on my FreeBSD 12.x machines. Thanks, Ali ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Issues with USB-C external monitors
On 01.12.2020 20:33, Poul-Henning Kamp wrote: > > > When I last tried this on my T480/T3-Dock/xorg, the screen comes back, but > xrandr shows it with ever increasing names "DP-3", "DP-4" etc. > > For now I've given up and use the T480's HDMI output instead. I've noticed that as well, the sys.class.drm.card0-DP-3 disappears and sys.class.drm.card0-DP-4 is created instead. I need to drive two external monitors, that's why I need the external dock. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Issues with USB-C external monitors
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 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Issues with USB-C external monitors
On 01.12.2020 17:10, myfreeweb wrote:
> >> __snippet__
> >> res = drmModeGetResources(fd);
> >> for (int i = 0; i < res->count_connectors; ++i) {
> >> conn = drmModeGetConnector(fd, res->connectors[i]);
>
> Note: you can run graphics/drm_info instead of writing custom code.
Thanks for the tip.
> devd (really drm in the kernel) provides hotplug events (system DRM, type
> HOTPLUG).
> libudev-devd translates these to UD_ACTION_HOTPLUG.
> This works well with wlroots compositors at least.
>
> How xorg does this I have no idea, as I don't use xorg.
> If your xorg is built with DEVD instead of UDEV option, it shouldn't work, I
> don't recall anyone adding support for that there.
> With UDEV it might work?
On current, for now I'm using the standard xorg-server from pkg, built
with UDEV according to [1], so apparently that is not working either. At
least in my case.
Will dig futher into it.
>
> >There is missing code in the kernel to handle USB-C PCI express
> >attach/detach. CC'ing Scott Long.
>
> Seems like this is about regular DisplayPort over USB-C (the USB side almost
> always handled in firmware for this on non-embedded computers).
> I don't think I've ever seen a *monitor* connecting over PCIe to an existing
> GPU ;)
> (in this case card0, the onboard vega)
Yes, this is just the DisplayPort over USB-C from the onboard vega GPU.
[1] https://www.freshports.org/x11-servers/xorg-server/
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Issues with USB-C external monitors
When I last tried this on my T480/T3-Dock/xorg, the screen comes back, but xrandr shows it with ever increasing names "DP-3", "DP-4" etc. For now I've given up and use the T480's HDMI output instead. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Issues with USB-C external monitors
> On Dec 1, 2020, at 10:32 AM, Ali Abdallah wrote:
>
> On 01.12.2020 17:10, myfreeweb wrote:
__snippet__
res = drmModeGetResources(fd);
for (int i = 0; i < res->count_connectors; ++i) {
conn = drmModeGetConnector(fd, res->connectors[i]);
>>
>> Note: you can run graphics/drm_info instead of writing custom code.
>
> Thanks for the tip.
>
>> devd (really drm in the kernel) provides hotplug events (system DRM, type
>> HOTPLUG).
>> libudev-devd translates these to UD_ACTION_HOTPLUG.
>> This works well with wlroots compositors at least.
>>
>> How xorg does this I have no idea, as I don't use xorg.
>> If your xorg is built with DEVD instead of UDEV option, it shouldn't work, I
>> don't recall anyone adding support for that there.
>> With UDEV it might work?
>
> On current, for now I'm using the standard xorg-server from pkg, built
> with UDEV according to [1], so apparently that is not working either. At
> least in my case.
>
> Will dig futher into it.
>
>>
>>> There is missing code in the kernel to handle USB-C PCI express
>>> attach/detach. CC'ing Scott Long.
>>
>> Seems like this is about regular DisplayPort over USB-C (the USB side almost
>> always handled in firmware for this on non-embedded computers).
>> I don't think I've ever seen a *monitor* connecting over PCIe to an existing
>> GPU ;)
>> (in this case card0, the onboard vega)
>
> Yes, this is just the DisplayPort over USB-C from the onboard vega GPU.
>
> [1] https://www.freshports.org/x11-servers/xorg-server/
>
>
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.
Scott
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Issues with USB-C external monitors
Hello,
I have a T495 with a USB-C docking station with two external monitors,
running current to get the vega 10 amdgpu to work.
When the power is lost for on the USB-C dock, then the X server looses
all external monitors. They appear as disconnected after running xrandr
and I cannot figure out a way to bring them back without killing my
current session and start X again, but that is very annoying...
I tried to debug the issue and I'm pretty sure that the X server on
FreeBSD is not reconfiguring the drm connectors automatically.
Let's say I have DP-4 as external connector, when the power is lost,
DP-4 disappears, when the power is back, DP-4 re-appear again but in
unknown status.
$ sysctl sys.class.drm | grep DP-4
sys.class.drm.card0-DP-4.modes:
sys.class.drm.card0-DP-4.dpms: Off
sys.class.drm.card0-DP-4.enabled: disabled
sys.class.drm.card0-DP-4.status: unknown
Now just running a simple libdrm code to rescan the connectors:
__snippet__
res = drmModeGetResources(fd);
for (int i = 0; i < res->count_connectors; ++i) {
conn = drmModeGetConnector(fd, res->connectors[i]);
After running the above code, the drm stack is somehow triggered to
re-read the DP-4.status, which appears now to be connected, but not
configured.
$ sysctl sys.class.drm | grep DP-4
sys.class.drm.card0-DP-4.modes: 1920x1080
sys.class.drm.card0-DP-4.dpms: Off
sys.class.drm.card0-DP-4.enabled: disabled
sys.class.drm.card0-DP-4.status: connected
I didn't dig further to see if I can trigger the X server to re-scan drm
connectors and eventually remove those that vanished, and add newly
detected connectors. On Linux that seems to work automatically.
Any thoughts?
Regards,
Ali.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Issues with USB-C external monitors
On December 1, 2020 2:00:55 PM UTC, Hans Petter Selasky
wrote:
>On 12/1/20 2:14 PM, Ali Abdallah wrote:
>> Hello,
>>
>> I have a T495 with a USB-C docking station with two external monitors,
>> running current to get the vega 10 amdgpu to work.
>>
>> When the power is lost for on the USB-C dock, then the X server looses
>> all external monitors. They appear as disconnected after running xrandr
>> and I cannot figure out a way to bring them back without killing my
>> current session and start X again, but that is very annoying...
>>
>> I tried to debug the issue and I'm pretty sure that the X server on
>> FreeBSD is not reconfiguring the drm connectors automatically.
>>
>> Let's say I have DP-4 as external connector, when the power is lost,
>> DP-4 disappears, when the power is back, DP-4 re-appear again but in
>> unknown status.
>>
>> $ sysctl sys.class.drm | grep DP-4
>> sys.class.drm.card0-DP-4.modes:
>> sys.class.drm.card0-DP-4.dpms: Off
>> sys.class.drm.card0-DP-4.enabled: disabled
>> sys.class.drm.card0-DP-4.status: unknown
>>
>> Now just running a simple libdrm code to rescan the connectors:
>>
>> __snippet__
>> res = drmModeGetResources(fd);
>> for (int i = 0; i < res->count_connectors; ++i) {
>> conn = drmModeGetConnector(fd, res->connectors[i]);
Note: you can run graphics/drm_info instead of writing custom code.
>> After running the above code, the drm stack is somehow triggered to
>> re-read the DP-4.status, which appears now to be connected, but not
>> configured.
>>
>> $ sysctl sys.class.drm | grep DP-4
>> sys.class.drm.card0-DP-4.modes: 1920x1080
>> sys.class.drm.card0-DP-4.dpms: Off
>> sys.class.drm.card0-DP-4.enabled: disabled
>> sys.class.drm.card0-DP-4.status: connected
>>
>> I didn't dig further to see if I can trigger the X server to re-scan drm
>> connectors and eventually remove those that vanished, and add newly
>> detected connectors. On Linux that seems to work automatically.
>>
>> Any thoughts?
devd (really drm in the kernel) provides hotplug events (system DRM, type
HOTPLUG).
libudev-devd translates these to UD_ACTION_HOTPLUG.
This works well with wlroots compositors at least.
How xorg does this I have no idea, as I don't use xorg.
If your xorg is built with DEVD instead of UDEV option, it shouldn't work, I
don't recall anyone adding support for that there.
With UDEV it might work?
>There is missing code in the kernel to handle USB-C PCI express
>attach/detach. CC'ing Scott Long.
Seems like this is about regular DisplayPort over USB-C (the USB side almost
always handled in firmware for this on non-embedded computers).
I don't think I've ever seen a *monitor* connecting over PCIe to an existing
GPU ;)
(in this case card0, the onboard vega)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Issues with USB-C external monitors
On 12/1/20 2:14 PM, Ali Abdallah wrote:
Hello,
I have a T495 with a USB-C docking station with two external monitors,
running current to get the vega 10 amdgpu to work.
When the power is lost for on the USB-C dock, then the X server looses
all external monitors. They appear as disconnected after running xrandr
and I cannot figure out a way to bring them back without killing my
current session and start X again, but that is very annoying...
I tried to debug the issue and I'm pretty sure that the X server on
FreeBSD is not reconfiguring the drm connectors automatically.
Let's say I have DP-4 as external connector, when the power is lost,
DP-4 disappears, when the power is back, DP-4 re-appear again but in
unknown status.
$ sysctl sys.class.drm | grep DP-4
sys.class.drm.card0-DP-4.modes:
sys.class.drm.card0-DP-4.dpms: Off
sys.class.drm.card0-DP-4.enabled: disabled
sys.class.drm.card0-DP-4.status: unknown
Now just running a simple libdrm code to rescan the connectors:
__snippet__
res = drmModeGetResources(fd);
for (int i = 0; i < res->count_connectors; ++i) {
conn = drmModeGetConnector(fd, res->connectors[i]);
After running the above code, the drm stack is somehow triggered to
re-read the DP-4.status, which appears now to be connected, but not
configured.
$ sysctl sys.class.drm | grep DP-4
sys.class.drm.card0-DP-4.modes: 1920x1080
sys.class.drm.card0-DP-4.dpms: Off
sys.class.drm.card0-DP-4.enabled: disabled
sys.class.drm.card0-DP-4.status: connected
I didn't dig further to see if I can trigger the X server to re-scan drm
connectors and eventually remove those that vanished, and add newly
detected connectors. On Linux that seems to work automatically.
Any thoughts?
There is missing code in the kernel to handle USB-C PCI express
attach/detach. CC'ing Scott Long.
--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
