My system has problems with the displayport connection. This is indicated by several problems that, at the first glance, do not have anything in common. The reason why I claim DP for being the cause, is that when I connect another monitor via DVI these problems just vanish. When I put monitor into sleep it won't wake up. Journal contains: [drm:intel_dp_start_link_train] *ERROR* failed to enable link and sometimes [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung Qt applications need a few seconds to start. And meanwhile freeze X. Today I had a complete never-ending system freeze. As a followup KDE start is painfully slow and accompanied by multiple freezes. I use an up-to-date Arch System on an i5-4590, using the Intel HD4600. Here is dmesg with drm.debug=0xe comandline. I cut about a million "[drm:drm_dp_i2c_do_msg] native defer" lines to make it cleaner. Intel drivers are installed. The config: # for i in /sys/module/i915/parameters/*; do echo $i=$(cat $i); done /sys/module/i915/parameters/disable_display=N /sys/module/i915/parameters/disable_power_well=1 /sys/module/i915/parameters/enable_cmd_parser=0 /sys/module/i915/parameters/enable_fbc=-1 /sys/module/i915/parameters/enable_hangcheck=Y /sys/module/i915/parameters/enable_ips=1 /sys/module/i915/parameters/enable_ppgtt=1 /sys/module/i915/parameters/enable_psr=0 /sys/module/i915/parameters/enable_rc6=-1 /sys/module/i915/parameters/fastboot=N /sys/module/i915/parameters/invert_brightness=0 /sys/module/i915/parameters/lvds_channel_mode=0 /sys/module/i915/parameters/lvds_downclock=0 /sys/module/i915/parameters/lvds_use_ssc=-1 /sys/module/i915/parameters/modeset=-1 /sys/module/i915/parameters/panel_ignore_lid=1 /sys/module/i915/parameters/powersave=1 /sys/module/i915/parameters/prefault_disable=N /sys/module/i915/parameters/preliminary_hw_support=0 /sys/module/i915/parameters/reset=Y /sys/module/i915/parameters/semaphores=-1 /sys/module/i915/parameters/vbt_sdvo_panel_type=-1

Is there a way to simulate a physical HDMI cable unplugging and replugging on a Linux system running Xorg with AMDGPU driver? In my Xfce system on X11, I have trouble with monitor output/connector detection. In particular, when the system transitions from the Rescueshell/GRUB to the distro login manager (lightdm), the monitor turns blackish grey, and the only fix I've found so far is by unplugging the monitor's HDMI and replugging, or by changing the monitor's own FreeSync setting (Options: Standard Engine, Ultimate Engine, Off) in that black screen state and doing Ctrl+Alt+F2, which I think effectively "resets" the HDMI connection. Using drm.edid= as a kernel boot option can help with the issue, but having a valid Xorg.conf in /usr/share/X11/xorg.conf.d/ basically makes it useless and recreates the blackscreen, as I think Xorg/AMDGPU (my graphics driver) takes over control of the graphical output and uses the edid or modeline in the Xorg.conf, once it gets to the initial pre-login/post-login stage in lightdm. This switchup probably confuses my monitor. But I want to have a Xorg.conf for proper functionality. The blackscreen isn't completely black, as in a no signal, but it's somewhat grey. If I switch TTYs, the screen will flicker and go grey again, but there'll be no display at this stage. It's like the monitor is detected, but there the signal isn't interpreted right. I want to know if there is any way to make the KMS/DRM driver think that the monitor has been disconnected and reconnected, without a real physical disconnect, so the driver refreshes all "connectors" and hopefully gives output to the monitor, possibly using a udev HOTPLUG event. According to the answers in this question: , it is possible to use udevadm trigger to masquerade udev events to specific devices in /sys subsystems. Or by directly using echo ACTION > /sys/class/SUBSYTEM/DEVICE/uevent From udevadm trigger --verbose --action=help /sys/class/drm/card0-HDMI-A-1 I get a list of all possible 'trigger' options:

add
remove
change
move
online
offline
bind
unbind

I've tried using all of them, but they don't do anything equivalent to a full replugging. The screen stays on the whole time. However 'change' using udevadm trigger --verbose --action=change /sys/class/drm/card0-HDMI-A-1 forces a rescan for the device EDID in dmesg:

[34870.335496] Registering platform device 'HDMI-A-1'. Parent at platform
[34870.335523] device: 'HDMI-A-1': device_add
[34870.335545] platform HDMI-A-1: No ACPI support
[34870.335553] bus: 'platform': add device HDMI-A-1
[34870.335720] bus: 'platform': remove device HDMI-A-1
[34870.335746] [drm] Got external EDID base block and 0 extensions from "edid/1920x1080.bin" for connector "HDMI-A-1"

This does not turn off the screen though, and so doesn't help with the problem. Is there any way to mention a specific key / ENV{ATTRIBUTE} when triggering a udev event? For example someone else's udev logs during a monitor unplug and replug cycle:

udevadm monitor --environment --udev 
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing

UDEV  [1370.249130] change   /devices/pci0000:00/0000:00:02.0/drm/card0 (drm)
ACTION=change
DEVNAME=/dev/dri/card0
DEVPATH=/devices/pci0000:00/0000:00:02.0/drm/card0
DEVTYPE=drm_minor
HOTPLUG=1
ID_FOR_SEAT=drm-pci-0000_00_02_0
ID_PATH=pci-0000:00:02.0
ID_PATH_TAG=pci-0000_00_02_0
MAJOR=226
MINOR=0
SEQNUM=1884
SUBSYSTEM=drm
TAGS=:seat:uaccess:
USEC_INITIALIZED=715

Here the main ACTION is "change", but is there a way *I* can specify that HOTPLUG=1 parameter? It's noteworthy that when *I* use udevadm monitor and do an unplug cycle, nothing shows up in output. But when switching TTYs to F2 then F7 (my GUI) using Ctrl+Alt+..., then I get this:

udevadm monitor --environment --udev
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing

UDEV  [4315.550505] add      /devices/platform/HDMI-A-1 (platform)
ACTION=add
DEVPATH=/devices/platform/HDMI-A-1
SUBSYSTEM=platform
MODALIAS=platform:HDMI-A-1
SEQNUM=3714
USEC_INITIALIZED=4315229577
ID_PATH=platform-HDMI-A-1
ID_PATH_TAG=platform-HDMI-A-1

UDEV  [4315.551278] remove   /devices/platform/HDMI-A-1 (platform)
ACTION=remove
DEVPATH=/devices/platform/HDMI-A-1
SUBSYSTEM=platform
MODALIAS=platform:HDMI-A-1
SEQNUM=3715
USEC_INITIALIZED=4315229577
ID_PATH=platform-HDMI-A-1
ID_PATH_TAG=platform-HDMI-A-1

which could indicate that hotplugging is not supported or triggered properly in my system, leading to my issues. I found a Gentoo forum post: which had my same question regarding unplug and replug, but there was not a solution there. I have tried echo off > /sys/class/drm/card0-HDMI-A-1/status and echo on > /sys/class/drm/card0-HDMI-A-1/status but it doesn't cause the monitor to turn off, only an EDID rescan in dmesg. The same thing as a udevadm trigger --action=change. echoing to enabled or dpms in that same directory doesn't seem to be allowed. I have tried xset -display :0 dpms force off (or -display :0.0) from a TTY/shell script, but it doesn't turn off the monitor. Though it works in a GUI of course, after I've already unplugged the monitor once. I tried

sudo mount -o remount,exec /dev
sudo vbetool dpms off
sudo mount -o remount,noexec /dev

from [this](https://old.reddit.com/r/linux4noobs/comments/vo7u7l/how_can_i_turn_the_display_off_in_a_tty/) and [this](https://askubuntu.com/questions/1384221/real-mode-call-failed-on-macbook-pro-when-trying-to-turn-screen-off-ubuntu-serve) , but it outputs Real mode call failed. So now I tried setterm --blank 1 from and consoleblank=200 (approximate bootup time for my device in seconds) as a kernel commandline parameter, and they also don't work as I want them to. They can turn off the screen, but it's not a hard enough reset that makes the monitor redetected like in a physical replugging. I've tried a systemd service like this ExecStart=/bin/sh -c 'while [ -n "$(pidof lightdm)" ] || [ -n "$(pidof X)" ] || [ -n "$(pidof Xorg)" ]; do sleep 10; done; sleep 15; echo '' > /sys/module/drm/parameters/edid_firmware && pkill X' to restart X at the login prompt, but it doesn't help either. I came across this guide , which mentioned > void (*output_poll_changed)(struct drm_device *dev); > >This operation notifies the driver that the status of one or more connectors has changed. Drivers that use the fb helper can just call the drm_fb_helper_hotplug_event function to handle this operation. Is there a way I can compile a binary and call this function manually at X startup, to achieve what I'm looking for? Or is there any other solution to address this? I am having this issue on a PS4 system running Arch Linux, and I think the monitor might have trouble with EDID communication. So the hardware situation is a bit flaky, but most of the underlying mechanics are still the same.

On AlmaLinux 8.10, how to make Chromium "Version 133.0.6943.141 (Official version) Fedora Project 64 bits" use Widevine DRM without needing to install Google Chrome? The (alternative) Install Widevine alone without Google Chrome method detailed on the "proprietary/chromium-widevine" repository on GitHub is not being able to make the two software cooperate, as confirmed by Bitmovin's DRM Stream Test . I don't know if it could be a solution, but I tried to replace chromium by chromium-freeworld to see it the added codecs it promises would solve my problem, but the GetPageSpeed requires me to pay for a subscription to their repository. I see no advantage in paying to download chromium. TheTechLife 's tutorial is not for RHEL-based distros and cannot be followed. I did as Andrea Fortuna instructed, but the tutorial is more than 5 years old and does not work anymore.

I'm porting an embedded Linux device to mainline from a vendor kernel. I am almost there but there is one issue I can't seem to get rid of, which is DRM initializing very slowly. Here's the setup: SOC: imx8mp Kernel: 6.12 OS: Debian 12 bookworm The gpu seems to initialize at a reasonable time:

[    4.984644] etnaviv etnaviv: bound 38000000.gpu (ops gpu_ops [etnaviv])
[    5.005189] etnaviv etnaviv: bound 38008000.gpu (ops gpu_ops [etnaviv])
[    5.038057] etnaviv etnaviv: bound 38500000.npu (ops gpu_ops [etnaviv])
[    5.048542] etnaviv-gpu 38000000.gpu: model: GC7000, revision: 6204
[    5.060472] etnaviv-gpu 38008000.gpu: model: GC520, revision: 5341
[    5.087467] etnaviv-gpu 38500000.npu: model: GC8000, revision: 8002
[    5.101070] etnaviv-gpu 38500000.npu: etnaviv has been instantiated on a NPU, for which the UAPI is still experimental
[    5.121842] [drm] Initialized etnaviv 1.4.0 for etnaviv on minor 0

systemd takes over at about:

[    2.318927] systemd: systemd 252.33-1~deb12u1 running in system mode (+PAM +AUDIT
+SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL
+ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT
+QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT
default-hierarchy=unified)

But then there is a second round of DRM initialization which actually enables the display stream:

[    6.904837] imx-dwmac 30bf0000.ethernet end0: Register MEM_TYPE_PAGE_POOL RxQ-0
[    6.971593] imx-dwmac 30bf0000.ethernet end0: PHY [stmmac-0:00] driver [SMSC LAN8710/LAN8720] (irq=147)
[    6.987060] imx-dwmac 30bf0000.ethernet end0: No Safety Features support found
[    6.994331] imx-dwmac 30bf0000.ethernet end0: IEEE 1588-2008 Advanced Timestamp supported
[    7.002765] imx-dwmac 30bf0000.ethernet end0: registered PTP clock
[    7.009583] imx-dwmac 30bf0000.ethernet end0: configuring for phy/rmii link mode
[    8.601862] imx-dwmac 30bf0000.ethernet end0: Link is Up - 100Mbps/Full - flow control rx/tx
[   15.334021] samsung-dsim 32e60000.dsi: supply vddcore not found, using dummy regulator
[   15.343694] samsung-dsim 32e60000.dsi: supply vddio not found, using dummy regulator
[   15.365379] samsung-dsim 32e60000.dsi: [drm:samsung_dsim_host_attach [samsung_dsim]] Attached sn65dsi83 device (lanes:4 bpp:24 mode-flags:0x2e3)
[   15.380621] [drm] Initialized imx-lcdif 1.0.0 for 32e80000.display-controller on minor 1
[   15.522131] Console: switching to colour frame buffer device 240x45
[   15.555056] imx-lcdif 32e80000.display-controller: [drm] fb0: imx-lcdifdrmfb frame buffer device
[   15.592315] dw100 32e30000.dwe: dw100 v4l2 m2m registered as /dev/video0
[   15.601817] hantro-vpu 38300000.video-codec: registered nxp,imx8mm-vpu-g1-dec as /dev/video1
[   15.611540] hantro-vpu 38310000.video-codec: registered nxp,imx8mq-vpu-g2-dec as /dev/video2

There is just a random gap of 10 seconds between these two rounds of initialization and I don't understand why. systemd-analyze:

systemd-analyze
Startup finished in 2.034s (kernel) + 4.558s (userspace) = 6.592s 
graphical.target reached after 4.450s in userspace.

Thanks in advance for any help!

I am very new to linux and as such would appreciate any pointers with respect to understanding system calls and having the ability, knowledge and tools to reverse-engineer their origin or their process flow. As the title suggests, i present an example, being my analysis of an Xorg process that i traced in my linux desktop environment. As such, i am attempting to understand the process flow of DRM_IOCTL calls, in this case a specific DRM_IOCTL_CURSOR2 system call that takes place within the process. My goal is to understand what triggers this call within this desktop environment, or rather what steps I can take in general to investigate inquiries like this From my limited understanding I am aware that Xorg is spawned as a subprocess of SDDM but aside from initiating the Xorg server, I am at a blank in trying to figure out how to walk through the process and identify triggers for certain process calls or perhaps the use of tools to do so. As such this is a conceptual question on how to approach analyses such as this in general. Would this require specific knowledge of the process at hand and its architecture. Would there be any general approaches I can take on my system to trace systemcalls much like deducing ppids of processes for my own interest. As of now I have vague familiarity using tools like strace, bpftrace and general command line tools like ps & lsof. Apologies if this is a broad question, if so I will be happy to narrow it further

I need to change the standard resolution for my DRM mode. How can I achieve that? When I do cat on

cat /sys/class/drm/card0/card0-HDMI-A-1/modes

1920x1080
1920x1080
1920x1080
1280x720
1280x720
1280x720
720x576
720x576
720x480
720x480

The problem is my HDMI screen cannot support 1920x1080. My HDMI screen support 1280x720 and below. So how can I tell DRM to not use 1920x1080?

I created one Linux(STM32MP157 Olinuxino) application which uses DRM and OpenGL libs. The app is running without any issues when started from terminal. My application calls drmModePageFlip() twice with an interval of 1 second sometimes to show an effect like button click. I can see button click effect after 5 hours also when app is running in terminal. To start this app at boot time, I created a service as below and enabled it. [Unit] Description=ODRAW GUI Runtime After=systemd-user-sessions.service [Service] Type=simple Restart=always RestartSec=1 User=root ExecStart=/home/olimex/my_drm_app [Install] WantedBy=graphical.target Now the app is running immediately after Linux boots and I am unable to see the button click effect after 1 minute onwards. When I see the debug messages using **journalctl** I found that **drmModePageFlip()** failed when I call it second time for button click effect. And also during wait for flip completion I am getting user interruption. Below is the code for page flipping part. ret = drmModePageFlip(xDRM.fd, xDRM.crtc_id, gbm_fb->fb_id, DRM_MODE_PAGE_FLIP_EVENT, &waiting_for_flip); if(ret) { printf("failed to queue page flip: %s\n", strerror(errno)); } else { while(waiting_for_flip) { ret = select(xDRM.fd + 1, &fds, NULL, NULL, NULL); if (ret < 0) { printf("select err: %s\n", strerror(errno)); break;//return ret; } else if (ret == 0) { printf("select timeout!\n"); break;//return -1; } else if (FD_ISSET(0, &fds)) { printf("user interrupted!\n"); break; } drmHandleEvent(xDRM.fd, &evctx); } } Any idea to fix this issue will be helpful to me. Thanks in advance.

I have a monitor LG E2251 (monitor [details](https://www.lg.com/uk/monitors/lg-E2251VR-led-monitor)) . My computer was connected to the monitor via DVI-I cable; after the power supply broke, the display went black. I rebooted the system and all seemed ok. I pass the POST as usual, however I cannot see the GUI nor CLI when connected with DVI-I. I believe the EDID code for DVI-I has been corrupted. I also tried with other 2 connections: whether HDMI doesn't present any damge,I get the following message for DVI-I

nouveau 0000:01:00.0: DRM: VRAM: 1024 MiB
[    9.292129] nouveau 0000:01:00.0: DRM: GART: 1048576 MiB
[    9.292133] nouveau 0000:01:00.0: DRM: TMDS table version 2.0
[    9.292135] nouveau 0000:01:00.0: DRM: DCB version 4.0
[    9.292137] nouveau 0000:01:00.0: DRM: DCB outp 00: 01000302 00020030
[    9.292139] nouveau 0000:01:00.0: DRM: DCB outp 01: 02000300 00000000
[    9.292141] nouveau 0000:01:00.0: DRM: DCB outp 02: 02011362 00020010
[    9.292143] nouveau 0000:01:00.0: DRM: DCB outp 03: 01022310 00000000
[    9.292145] nouveau 0000:01:00.0: DRM: DCB conn 00: 00001030
[    9.292146] nouveau 0000:01:00.0: DRM: DCB conn 01: 00002161
[    9.292148] nouveau 0000:01:00.0: DRM: DCB conn 02: 00000200
[    9.296293] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    9.296294] [drm] Driver supports precise vblank timestamp query.
[    9.309393] nouveau 0000:01:00.0: DRM: MM: using COPY for buffer copies
 [drm:drm_edid_block_valid [drm]] *ERROR* EDID checksum is invalid, remainder is 185
[    9.449801] nouveau 0000:01:00.0: DVI-I-1: EDID block 0 invalid.
[    9.449803] nouveau 0000:01:00.0: DRM: DDC responded, but no EDID for DVI-I-1
[    9.470675] nouveau 0000:01:00.0: No connectors reported connected with modes
[    9.470678] [drm] Cannot find any crtc or sizes - going 1024x768
[    9.472105] nouveau 0000:01:00.0: DRM: allocated 1024x768 fb: 0x70000, bo ffff9d41b8eafc00
[    9.472196] fbcon: nouveaufb (fb0) is primary device
[    9.474979] Console: switching to colour frame buffer device 128x48
[    9.476170] nouveau 0000:01:00.0: fb0: nouveaufb frame buffer device
[    9.508021] [drm] Initialized nouveau 1.3.1 20120801 for 0000:01:00.0 on minor 0

and a similar one for VGA

[drm:drm_edid_block_valid [drm]] *ERROR* EDID checksum is invalid, remainder is 198
[   95.783329] nouveau 0000:01:00.0: VGA-1: EDID block 0 invalid.
[   95.783331] nouveau 0000:01:00.0: DRM: DDC responded, but no EDID for VGA-1

# MY APPROACH - installed i2c-tools on my debian machine. - found i2c-1 to be my DVI interface - with i2cdump -y 1 0x50 I can dump the EDID code. ## i2cset However, when I want to set a block of bytes with i2cset -y 1 0x50 0x00 0x00 0xff i EDID does not change. **How can I correct those EDID?** Is there a fast solution in the UserSpace, without assembly programming? I say I'm new to EDID, nouveau driver, I2C or SMBus communication. Any advice and correction is appreciated. It looks like I could send BLOCKs of bytes on that I2C BUS i2cdetect -F 1:

Functionalities implemented by /dev/i2c-1:
I2C Block Write                  yes
I2C Block Read                   yes
...

but I don't know what's wrong. ### LINKS + [wikipedia/EDID](https://en.wikipedia.org/wiki/Extended_Display_Identification_Data) + [read EDID](https://unix.stackexchange.com/q/7763/354095) + [i2cget](https://stackoverflow.com/q/44550692/11368129) + [i2cset](https://stackoverflow.com/q/50556657/11368129)

I have a amdgpu, using the open source driver. amdgpu driver claims to do early kms by default, but the early is very late. Exactly 2.5s! I wouldn't care much but it breaks and delays my disk encryption password prompt. the laptop already boots with EFI video which is perfectly usable and correct. then DRM/KMS loads, and screw ups the size and fonts for the tty. Then sd-vconsole starts and corrects it. Hence I'm trying to either delay kms or force it to be *really* early. things that failed: 1. forcing edid

- # get-edid > myedid.bin
- do the dance to put file in initfs
- adding drm.edid_firmware=edid/myedid.bin to kernel parameters

it fails with "invalid firmware" but doesn't matter, i still get the error right on top of my sd-encrypt prompt, so it would not help move it early/later. 2. early kms hook. tried this weird mkinitcpio.conf list for the hooks

HOOKS=(systemd kms autodetect modconf keyboard sd-vconsole block sd-encrypt microcode lvm2 filesystems fsck)

still happens late. 3. forcing the right tty size/font thinking i can't win, i try to join kms and just tell it what to set things to when it comes crashing in. Added any combination of video=efifb fbcon=font:iso01-12x22 fbcon=nodefer video=eDP-1:1920x1200@60.03 (which is what sd-vconfig sets) it still ignores the font, and while it always set the display to the right resolution, the virtual resolution for the tty get's cut in 1/4 which breaks all the text for a while. And still starts at 2.5s into the boot. 4. bundling amdgpu firmware in initfs reading on https://forums.gentoo.org/viewtopic-p-8789979.html i added FILES=(/usr/lib/firmware/amdgpu/*) to mkinitcpio.conf nothing changes.

I'm confused about what is what nowadays with Linux and video support for the console interface vs X. Do the /dev/fb* items only relate to the old original framebuffer support? Does DRM create/support /dev/fb* items. How does KMS fit in to all of this? Do you still need at least the generic frame buffer support for VESA or EFI to have console support? TIA!!

I'm trying to debug why I can't have all my screens on at the same time. In order to zero in on the problem, I am hoping to find an easy way to control my screens without involving X11 or wayland - just a program that turns a screen red for example that I can use in tty mode. Is this possible? Another thing that might help is if there is a way to configure which screens do and don't show the terminal. You know how usually all the screens show the terminal, but if you plug in the screen while X11 is running, and don't activate it, something it doesn't show the terminal in TTY mode? There must be a way to turn screens on and off in TTY mode right? I guess I am just looking for any way to display something on a monitor or turn it on and off without X11 running. I'd even be happy to ssh into my machine, and control the screens that way if there is a way to turn off the console completely.

I would like to automatically change my xrandr settings depending on whether my second monitor (a Smart TV) is switched on or off. No check or utility that I could think of could differentiate between the off (standby) and on ("waiting for signal") states. However, turning the TV on will cause four events to show up in udevadm monitor --property, so I am sure that **some** part of the system must know about the state of the TV...

KERNEL[14640.475012] change   /devices/pci0000:00/0000:00:01.1/0000:01:00.0/0000:02:00.0/0000:03:00.0/drm/card0 (drm)
ACTION=change
DEVPATH=/devices/pci0000:00/0000:00:01.1/0000:01:00.0/0000:02:00.0/0000:03:00.0/drm/card0
SUBSYSTEM=drm
HOTPLUG=1
CONNECTOR=99
DEVNAME=/dev/dri/card0
DEVTYPE=drm_minor
SEQNUM=4821
MAJOR=226
MINOR=0

UDEV  [14640.477739] change   /devices/pci0000:00/0000:00:01.1/0000:01:00.0/0000:02:00.0/0000:03:00.0/drm/card0 (drm)
ACTION=change
DEVPATH=/devices/pci0000:00/0000:00:01.1/0000:01:00.0/0000:02:00.0/0000:03:00.0/drm/card0
SUBSYSTEM=drm
HOTPLUG=1
CONNECTOR=99
DEVNAME=/dev/dri/card0
DEVTYPE=drm_minor
SEQNUM=4821
USEC_INITIALIZED=7772035
ID_PATH=pci-0000:03:00.0
ID_PATH_TAG=pci-0000_03_00_0
ID_FOR_SEAT=drm-pci-0000_03_00_0
MAJOR=226
MINOR=0
DEVLINKS=/dev/dri/by-path/pci-0000:03:00.0-card
TAGS=:master-of-seat:seat:uaccess:
CURRENT_TAGS=:master-of-seat:seat:uaccess:

KERNEL[14641.187063] change   /devices/pci0000:00/0000:00:01.1/0000:01:00.0/0000:02:00.0/0000:03:00.0/drm/card0 (drm)
ACTION=change
DEVPATH=/devices/pci0000:00/0000:00:01.1/0000:01:00.0/0000:02:00.0/0000:03:00.0/drm/card0
SUBSYSTEM=drm
HOTPLUG=1
CONNECTOR=99
DEVNAME=/dev/dri/card0
DEVTYPE=drm_minor
SEQNUM=4822
MAJOR=226
MINOR=0

UDEV  [14641.188317] change   /devices/pci0000:00/0000:00:01.1/0000:01:00.0/0000:02:00.0/0000:03:00.0/drm/card0 (drm)
ACTION=change
DEVPATH=/devices/pci0000:00/0000:00:01.1/0000:01:00.0/0000:02:00.0/0000:03:00.0/drm/card0
SUBSYSTEM=drm
HOTPLUG=1
CONNECTOR=99
DEVNAME=/dev/dri/card0
DEVTYPE=drm_minor
SEQNUM=4822
USEC_INITIALIZED=7772035
ID_PATH=pci-0000:03:00.0
ID_PATH_TAG=pci-0000_03_00_0
ID_FOR_SEAT=drm-pci-0000_03_00_0
MAJOR=226
MINOR=0
DEVLINKS=/dev/dri/by-path/pci-0000:03:00.0-card
TAGS=:master-of-seat:seat:uaccess:
CURRENT_TAGS=:master-of-seat:seat:uaccess:

I can also see messages in /var/log/Xorg.0.log whenever the TV is switched from standby to on:

[ 18229.550] (II) AMDGPU(0): EDID vendor "HPN", prod id 14116
[ 18229.550] (II) AMDGPU(0): Using hsync ranges from config file
[ 18229.550] (II) AMDGPU(0): Using vrefresh ranges from config file
[ 18229.550] (II) AMDGPU(0): Printing DDC gathered Modelines:
[ 18229.551] (II) AMDGPU(0): Modeline "2560x1440"x0.0  241.50  2560 2608 2640 2720  1440 1443 1448 1481 +hsync -vsync (88.8 kHz eP)
[ 18229.551] (II) AMDGPU(0): Modeline "2560x1440"x0.0  604.25  2560 2608 2640 2720  1440 1443 1448 1543 +hsync -vsync (222.2 kHz e)
[ 18229.551] (II) AMDGPU(0): Modeline "2560x1440"x0.0  497.75  2560 2608 2640 2720  1440 1443 1448 1525 +hsync +vsync (183.0 kHz e)
[ 18229.551] (II) AMDGPU(0): Modeline "2560x1440"x0.0  304.25  2560 2608 2640 2720  1440 1443 1448 1492 +hsync -vsync (111.9 kHz e)
[ 18229.551] (II) AMDGPU(0): Modeline "1920x1080"x0.0  148.50  1920 2008 2052 2200  1080 1084 1089 1125 +hsync +vsync (67.5 kHz e)
[ 18229.551] (II) AMDGPU(0): Modeline "1280x720"x0.0   74.25  1280 1390 1430 1650  720 725 730 750 +hsync +vsync (45.0 kHz e)
[ 18229.551] (II) AMDGPU(0): Modeline "720x480"x0.0   27.00  720 736 798 858  480 489 495 525 -hsync -vsync (31.5 kHz e)
[ 18229.551] (II) AMDGPU(0): Modeline "640x480"x0.0   25.18  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz e)
[ 18229.551] (II) AMDGPU(0): Modeline "1920x1080"x0.0  297.00  1920 2008 2052 2200  1080 1084 1089 1125 +hsync +vsync (135.0 kHz e)
[ 18229.551] (II) AMDGPU(0): Modeline "1920x1080"x0.0  297.00  1920 2448 2492 2640  1080 1084 1094 1125 +hsync +vsync (112.5 kHz e)
[ 18229.551] (II) AMDGPU(0): Modeline "800x600"x0.0   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz e)
[ 18229.551] (II) AMDGPU(0): Modeline "720x400"x0.0   28.32  720 738 846 900  400 412 414 449 -hsync +vsync (31.5 kHz e)
[ 18229.551] (II) AMDGPU(0): Modeline "1024x768"x0.0   65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz e)
[ 18229.551] (II) AMDGPU(0): Modeline "1920x1200"x0.0  193.25  1920 2056 2256 2592  1200 1203 1209 1245 -hsync +vsync (74.6 kHz e)
[ 18229.551] (II) AMDGPU(0): Modeline "1680x1050"x0.0  146.25  1680 1784 1960 2240  1050 1053 1059 1089 -hsync +vsync (65.3 kHz e)
[ 18229.551] (II) AMDGPU(0): Modeline "(null)"x59.9  118.25  1600 1696 1856 2112  900 903 908 934 -hsync +vsync (56.0 kHz e)
[ 18229.551] (II) AMDGPU(0): Modeline "1440x900"x0.0  106.50  1440 1520 1672 1904  900 903 909 934 -hsync +vsync (55.9 kHz e)
[ 18229.551] (II) AMDGPU(0): Modeline "1280x1024"x0.0  108.00  1280 1328 1440 1688  1024 1025 1028 1066 +hsync +vsync (64.0 kHz e)
[ 18229.551] (II) AMDGPU(0): Modeline "1280x800"x0.0   83.50  1280 1352 1480 1680  800 803 809 831 -hsync +vsync (49.7 kHz e)
[ 18230.263] (--) AMDGPU(0): HDMI max TMDS frequency 300000KHz
[ 18230.266] (II) AMDGPU(0): EDID vendor "HPN", prod id 14116
[ 18230.266] (II) AMDGPU(0): Using hsync ranges from config file
[ 18230.266] (II) AMDGPU(0): Using vrefresh ranges from config file
[ 18230.266] (II) AMDGPU(0): Printing DDC gathered Modelines:
[ 18230.266] (II) AMDGPU(0): Modeline "2560x1440"x0.0  241.50  2560 2608 2640 2720  1440 1443 1448 1481 +hsync -vsync (88.8 kHz eP)
[ 18230.266] (II) AMDGPU(0): Modeline "2560x1440"x0.0  604.25  2560 2608 2640 2720  1440 1443 1448 1543 +hsync -vsync (222.2 kHz e)
[ 18230.266] (II) AMDGPU(0): Modeline "2560x1440"x0.0  497.75  2560 2608 2640 2720  1440 1443 1448 1525 +hsync +vsync (183.0 kHz e)
[ 18230.266] (II) AMDGPU(0): Modeline "2560x1440"x0.0  304.25  2560 2608 2640 2720  1440 1443 1448 1492 +hsync -vsync (111.9 kHz e)
[ 18230.266] (II) AMDGPU(0): Modeline "1920x1080"x0.0  148.50  1920 2008 2052 2200  1080 1084 1089 1125 +hsync +vsync (67.5 kHz e)
[ 18230.266] (II) AMDGPU(0): Modeline "1280x720"x0.0   74.25  1280 1390 1430 1650  720 725 730 750 +hsync +vsync (45.0 kHz e)
[ 18230.266] (II) AMDGPU(0): Modeline "720x480"x0.0   27.00  720 736 798 858  480 489 495 525 -hsync -vsync (31.5 kHz e)
[ 18230.266] (II) AMDGPU(0): Modeline "640x480"x0.0   25.18  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz e)
[ 18230.266] (II) AMDGPU(0): Modeline "1920x1080"x0.0  297.00  1920 2008 2052 2200  1080 1084 1089 1125 +hsync +vsync (135.0 kHz e)
[ 18230.266] (II) AMDGPU(0): Modeline "1920x1080"x0.0  297.00  1920 2448 2492 2640  1080 1084 1094 1125 +hsync +vsync (112.5 kHz e)
[ 18230.266] (II) AMDGPU(0): Modeline "800x600"x0.0   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz e)
[ 18230.266] (II) AMDGPU(0): Modeline "720x400"x0.0   28.32  720 738 846 900  400 412 414 449 -hsync +vsync (31.5 kHz e)
[ 18230.266] (II) AMDGPU(0): Modeline "1024x768"x0.0   65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz e)
[ 18230.266] (II) AMDGPU(0): Modeline "1920x1200"x0.0  193.25  1920 2056 2256 2592  1200 1203 1209 1245 -hsync +vsync (74.6 kHz e)
[ 18230.266] (II) AMDGPU(0): Modeline "1680x1050"x0.0  146.25  1680 1784 1960 2240  1050 1053 1059 1089 -hsync +vsync (65.3 kHz e)
[ 18230.266] (II) AMDGPU(0): Modeline "(null)"x59.9  118.25  1600 1696 1856 2112  900 903 908 934 -hsync +vsync (56.0 kHz e)
[ 18230.266] (II) AMDGPU(0): Modeline "1440x900"x0.0  106.50  1440 1520 1672 1904  900 903 909 934 -hsync +vsync (55.9 kHz e)
[ 18230.266] (II) AMDGPU(0): Modeline "1280x1024"x0.0  108.00  1280 1328 1440 1688  1024 1025 1028 1066 +hsync +vsync (64.0 kHz e)
[ 18230.266] (II) AMDGPU(0): Modeline "1280x800"x0.0   83.50  1280 1352 1480 1680  800 803 809 831 -hsync +vsync (49.7 kHz e)

Here's some information about my system and setup: The TV (Vestel, production year 2015, branded as "Telefunken") is connected via a DisplayPort-to-HDMI cable to my graphics card (AMD Radeon RX 6700 XT), which is in turn controlled by the amdgpu driver. I'm using X11 and i3wm on a Debian Sid system.

mic@mic:~$ uname -a
Linux mic 6.5.0-3-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.5.8-1 (2023-10-22) x86_64 GNU/Linux
mic@mic:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux trixie/sid
Release:        n/a
Codename:       trixie

I checked the following commands and places for any indications that might tell me whether the TV is in standby:

mic@mic:~$ xrandr --verbose
Screen 0: minimum 320 x 200, current 2560 x 1440, maximum 16384 x 16384
DisplayPort-0 connected primary (normal left inverted right x axis y axis)
        Identifier: 0x54
        Timestamp:  10692081
        Subpixel:   unknown
        Clones:    
        CRTCs:      0 1 2 3 4 5
        Transform:  1.000000 0.000000 0.000000
                    0.000000 1.000000 0.000000
                    0.000000 0.000000 1.000000
                   filter: 
        EDID: 
                00ffffffffffff0058b3003700000000
                01190103805932780acf74a3574cb023
                09484cafef80b3009500a94090408100
                81808140010108e80030f2705a80b058
                8a00501d7400001e023a801871382d40
                582c4500501d7400001e000000fc0034
                305548445f4c43445f54560a000000fd
                00303e0f463c000a20202020202001d0
                020344f15c0106070203151611121304
                14051f902021225d5e5f606162636465
                6629090707150750570600830100006e
                030c001000f83c20008004030201e50f
                0000600c011d803e73382d407e2c4580
                00d05200001e011d80d0721c2d20102c
                258000d05200009e0000000000000000
                00000000000000000000000000000013
        GAMMA_LUT_SIZE: 4096 
                range: (0, -1)
        DEGAMMA_LUT_SIZE: 4096 
                range: (0, -1)
        GAMMA_LUT: 0 
                range: (0, 65535)
        CTM: 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 
                0 1 
        DEGAMMA_LUT: 0 
                range: (0, 65535)
        TearFree: auto 
                supported: off, on, auto
        subconnector: HDMI 
                supported: Unknown, VGA, DVI-D, HDMI, DP, Wireless, Native
        HDCP Content Type: HDCP Type0 
                supported: HDCP Type0, HDCP Type1
        Content Protection: Undesired 
                supported: Undesired, Desired, Enabled
        vrr_capable: 0 
                range: (0, 1)
        Colorspace: Default 
                supported: Default, BT709_YCC, opRGB, BT2020_RGB, BT2020_YCC
        max bpc: 16 
                range: (8, 16)
        underscan vborder: 0 
                range: (0, 128)
        underscan hborder: 0 
                range: (0, 128)
        underscan: off 
                supported: off, on, auto
        scaling mode: None 
                supported: None, Full, Center, Full aspect
        link-status: Good 
                supported: Good, Bad
        CONNECTOR_ID: 99 
                supported: 99
        non-desktop: 0 
                range: (0, 1)
  1920x1080 (0x59) 148.500MHz +HSync +VSync
        h: width  1920 start 2008 end 2052 total 2200 skew    0 clock  67.50KHz
        v: height 1080 start 1084 end 1089 total 1125           clock  60.00Hz
  1920x1080 (0x5a) 148.500MHz +HSync +VSync
        h: width  1920 start 2448 end 2492 total 2640 skew    0 clock  56.25KHz
        v: height 1080 start 1084 end 1089 total 1125           clock  50.00Hz
  1920x1080 (0x5b) 148.352MHz +HSync +VSync
        h: width  1920 start 2008 end 2052 total 2200 skew    0 clock  67.43KHz
        v: height 1080 start 1084 end 1089 total 1125           clock  59.94Hz
  1920x1080 (0x5c) 74.250MHz +HSync +VSync
        h: width  1920 start 2008 end 2052 total 2200 skew    0 clock  33.75KHz
        v: height 1080 start 1084 end 1089 total 1125           clock  30.00Hz
  1920x1080 (0x5d) 74.250MHz +HSync +VSync
        h: width  1920 start 2448 end 2492 total 2640 skew    0 clock  28.12KHz
        v: height 1080 start 1084 end 1089 total 1125           clock  25.00Hz
  1920x1080 (0x5e) 74.250MHz +HSync +VSync
        h: width  1920 start 2558 end 2602 total 2750 skew    0 clock  27.00KHz
        v: height 1080 start 1084 end 1089 total 1125           clock  24.00Hz
  1920x1080 (0x5f) 74.176MHz +HSync +VSync
        h: width  1920 start 2008 end 2052 total 2200 skew    0 clock  33.72KHz
        v: height 1080 start 1084 end 1089 total 1125           clock  29.97Hz
  1920x1080 (0x60) 74.176MHz +HSync +VSync
        h: width  1920 start 2558 end 2602 total 2750 skew    0 clock  26.97KHz
        v: height 1080 start 1084 end 1089 total 1125           clock  23.98Hz
  1600x1200 (0x61) 162.000MHz +HSync +VSync
        h: width  1600 start 1664 end 1856 total 2160 skew    0 clock  75.00KHz
        v: height 1200 start 1201 end 1204 total 1250           clock  60.00Hz
  1680x1050 (0x62) 119.000MHz +HSync -VSync
        h: width  1680 start 1728 end 1760 total 1840 skew    0 clock  64.67KHz
        v: height 1050 start 1053 end 1059 total 1080           clock  59.88Hz
  1400x1050 (0x63) 101.000MHz +HSync -VSync
        h: width  1400 start 1448 end 1480 total 1560 skew    0 clock  64.74KHz
        v: height 1050 start 1053 end 1057 total 1080           clock  59.95Hz
  1280x1024 (0x64) 135.000MHz +HSync +VSync
        h: width  1280 start 1296 end 1440 total 1688 skew    0 clock  79.98KHz
        v: height 1024 start 1025 end 1028 total 1066           clock  75.02Hz
  1280x1024 (0x65) 108.000MHz +HSync +VSync
        h: width  1280 start 1328 end 1440 total 1688 skew    0 clock  63.98KHz
        v: height 1024 start 1025 end 1028 total 1066           clock  60.02Hz
  1440x900 (0x66) 88.750MHz +HSync -VSync
        h: width  1440 start 1488 end 1520 total 1600 skew    0 clock  55.47KHz
        v: height  900 start  903 end  909 total  926           clock  59.90Hz
  1280x960 (0x67) 108.000MHz +HSync +VSync
        h: width  1280 start 1376 end 1488 total 1800 skew    0 clock  60.00KHz
        v: height  960 start  961 end  964 total 1000           clock  60.00Hz
  1280x800 (0x68) 71.000MHz +HSync -VSync
        h: width  1280 start 1328 end 1360 total 1440 skew    0 clock  49.31KHz
        v: height  800 start  803 end  809 total  823           clock  59.91Hz
  1152x864 (0x69) 108.000MHz +HSync +VSync
        h: width  1152 start 1216 end 1344 total 1600 skew    0 clock  67.50KHz
        v: height  864 start  865 end  868 total  900           clock  75.00Hz
  1280x720 (0x6a) 74.250MHz +HSync +VSync
        h: width  1280 start 1390 end 1430 total 1650 skew    0 clock  45.00KHz
        v: height  720 start  725 end  730 total  750           clock  60.00Hz
  1280x720 (0x6b) 74.250MHz +HSync +VSync
        h: width  1280 start 1720 end 1760 total 1980 skew    0 clock  37.50KHz
        v: height  720 start  725 end  730 total  750           clock  50.00Hz
  1280x720 (0x6c) 74.176MHz +HSync +VSync
        h: width  1280 start 1390 end 1430 total 1650 skew    0 clock  44.96KHz
        v: height  720 start  725 end  730 total  750           clock  59.94Hz
  1024x768 (0x6d) 78.750MHz +HSync +VSync
        h: width  1024 start 1040 end 1136 total 1312 skew    0 clock  60.02KHz
        v: height  768 start  769 end  772 total  800           clock  75.03Hz
  1024x768 (0x6e) 75.000MHz -HSync -VSync
        h: width  1024 start 1048 end 1184 total 1328 skew    0 clock  56.48KHz
        v: height  768 start  771 end  777 total  806           clock  70.07Hz
  1024x768 (0x6f) 65.000MHz -HSync -VSync
        h: width  1024 start 1048 end 1184 total 1344 skew    0 clock  48.36KHz
        v: height  768 start  771 end  777 total  806           clock  60.00Hz
  832x624 (0x70) 57.284MHz -HSync -VSync
        h: width   832 start  864 end  928 total 1152 skew    0 clock  49.73KHz
        v: height  624 start  625 end  628 total  667           clock  74.55Hz
  800x600 (0x71) 50.000MHz +HSync +VSync
        h: width   800 start  856 end  976 total 1040 skew    0 clock  48.08KHz
        v: height  600 start  637 end  643 total  666           clock  72.19Hz
  800x600 (0x72) 49.500MHz +HSync +VSync
        h: width   800 start  816 end  896 total 1056 skew    0 clock  46.88KHz
        v: height  600 start  601 end  604 total  625           clock  75.00Hz
  800x600 (0x73) 40.000MHz +HSync +VSync
        h: width   800 start  840 end  968 total 1056 skew    0 clock  37.88KHz
        v: height  600 start  601 end  605 total  628           clock  60.32Hz
  800x600 (0x74) 36.000MHz +HSync +VSync
        h: width   800 start  824 end  896 total 1024 skew    0 clock  35.16KHz
        v: height  600 start  601 end  603 total  625           clock  56.25Hz
  720x576 (0x75) 27.000MHz -HSync -VSync
        h: width   720 start  732 end  796 total  864 skew    0 clock  31.25KHz
        v: height  576 start  581 end  586 total  625           clock  50.00Hz
  720x480 (0x76) 27.027MHz -HSync -VSync
        h: width   720 start  736 end  798 total  858 skew    0 clock  31.50KHz
        v: height  480 start  489 end  495 total  525           clock  60.00Hz
  720x480 (0x77) 27.000MHz -HSync -VSync
        h: width   720 start  736 end  798 total  858 skew    0 clock  31.47KHz
        v: height  480 start  489 end  495 total  525           clock  59.94Hz
  640x480 (0x78) 31.500MHz -HSync -VSync
        h: width   640 start  656 end  720 total  840 skew    0 clock  37.50KHz
        v: height  480 start  481 end  484 total  500           clock  75.00Hz
  640x480 (0x79) 31.500MHz -HSync -VSync
        h: width   640 start  664 end  704 total  832 skew    0 clock  37.86KHz
        v: height  480 start  489 end  492 total  520           clock  72.81Hz
  640x480 (0x7a) 25.200MHz -HSync -VSync
        h: width   640 start  656 end  752 total  800 skew    0 clock  31.50KHz
        v: height  480 start  490 end  492 total  525           clock  60.00Hz
  640x480 (0x7b) 25.175MHz -HSync -VSync
        h: width   640 start  656 end  752 total  800 skew    0 clock  31.47KHz
        v: height  480 start  490 end  492 total  525           clock  59.94Hz
  720x400 (0x7c) 28.320MHz -HSync +VSync
        h: width   720 start  738 end  846 total  900 skew    0 clock  31.47KHz
        v: height  400 start  412 end  414 total  449           clock  70.08Hz
DisplayPort-1 disconnected (normal left inverted right x axis y axis)
        Identifier: 0x55
        Timestamp:  10692081
        Subpixel:   unknown
        Clones:    
        CRTCs:      0 1 2 3 4 5
        Transform:  1.000000 0.000000 0.000000
                    0.000000 1.000000 0.000000
                    0.000000 0.000000 1.000000
                   filter: 
        GAMMA_LUT_SIZE: 4096 
                range: (0, -1)
        DEGAMMA_LUT_SIZE: 4096 
                range: (0, -1)
        GAMMA_LUT: 0 
                range: (0, 65535)
        CTM: 0 
        DEGAMMA_LUT: 0 
                range: (0, 65535)
        TearFree: auto 
                supported: off, on, auto
        subconnector: Unknown 
                supported: Unknown, VGA, DVI-D, HDMI, DP, Wireless, Native
        HDCP Content Type: HDCP Type0 
                supported: HDCP Type0, HDCP Type1
        Content Protection: Undesired 
                supported: Undesired, Desired, Enabled
        vrr_capable: 0 
                range: (0, 1)
        Colorspace: Default 
                supported: Default, BT709_YCC, opRGB, BT2020_RGB, BT2020_YCC
        max bpc: 16 
                range: (8, 16)
        underscan vborder: 0 
                range: (0, 128)
        underscan hborder: 0 
                range: (0, 128)
        underscan: off 
                supported: off, on, auto
        scaling mode: None 
                supported: None, Full, Center, Full aspect
        link-status: Good 
                supported: Good, Bad
        CONNECTOR_ID: 108 
                supported: 108
        non-desktop: 0 
                range: (0, 1)

mic@mic:~$ ddcutil detect
Invalid display
   I2C bus:  /dev/i2c-4
   DRM connector:           card0-DP-1
   EDID synopsis:
      Mfg id:               VES - Vestel Elektronik Sanayi ve Ticaret A. S.
      Model:                40UHD_LCD_TV
      Product code:         14080  (0x3700)
      Serial number:        
      Binary serial number: 0 (0x00000000)
      Manufacture year:     2015,  Week: 1
   DDC communication failed

mic@mic:/sys/class/drm/card0-DP-1$ cat connector_id dpms enabled modes status uevent 
99
Off
disabled
1920x1080
1920x1080
1920x1080
1920x1080
1920x1080
1920x1080
1920x1080
1920x1080
1920x1080
1920x1080
1600x1200
1680x1050
1400x1050
1280x1024
1280x1024
1440x900
1280x960
1280x800
1152x864
1280x720
1280x720
1280x720
1024x768
1024x768
1024x768
832x624
800x600
800x600
800x600
800x600
720x576
720x576
720x480
720x480
720x480
720x480
640x480
640x480
640x480
640x480
640x480
720x400
connected
DEVTYPE=drm_connector

mic@mic:/sys/class/drm/card0-DP-1$ xxd -g1 edid 
00000000: 00 ff ff ff ff ff ff 00 58 b3 00 37 00 00 00 00  ........X..7....
00000010: 01 19 01 03 80 59 32 78 0a cf 74 a3 57 4c b0 23  .....Y2x..t.WL.#
00000020: 09 48 4c af ef 80 b3 00 95 00 a9 40 90 40 81 00  .HL........@.@..
00000030: 81 80 81 40 01 01 08 e8 00 30 f2 70 5a 80 b0 58  ...@.....0.pZ..X
00000040: 8a 00 50 1d 74 00 00 1e 02 3a 80 18 71 38 2d 40  ..P.t....:..q8-@
00000050: 58 2c 45 00 50 1d 74 00 00 1e 00 00 00 fc 00 34  X,E.P.t........4
00000060: 30 55 48 44 5f 4c 43 44 5f 54 56 0a 00 00 00 fd  0UHD_LCD_TV.....
00000070: 00 30 3e 0f 46 3c 00 0a 20 20 20 20 20 20 01 d0  .0>.Fs8-@~,E.
000000d0: 00 d0 52 00 00 1e 01 1d 80 d0 72 1c 2d 20 10 2c  ..R.......r.- .,
000000e0: 25 80 00 d0 52 00 00 9e 00 00 00 00 00 00 00 00  %...R...........
000000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 13  ................

But none of these files showed any changes. Neither did the Xorg logs or udevadm events contain any indication as to whether the TV is on or off.

An article summarizes the steps involved in 3D rendering with OpenGL in this way: > 1. Your program starts up, using “OpenGL” to draw. > 2. A library, “Mesa”, implements the OpenGL API. It uses card-specific drivers to translate the API into a hardware-specific form. If the driver uses Gallium internally, there’s a shared component that turns the OpenGL API into a common intermediate representation, TGSI. The API is passed through Gallium, and all the device-specific driver does is translate from TGSI into hardware commands, > 3. libdrm uses special secret card-specific ioctls to talk to the Linux kernel > 4. The Linux kernel, having special permissions, can allocate memory on and for the card. > 5. Back out at the Mesa level, Mesa uses DRI2 to talk to Xorg to make sure that buffer flips and window positions, etc. are synchronized. I don't understand step 3. In step 2, the device driver for GPU, which is in kernel space, produces "hardware commands". Then these hardware commands are given to libdrm which is in user space?! I thought that the device driver interacts directly with the GPU itself. What is the role of libdrm here?

I have tried to enable the DRM by setting this kernel parameter in Manjaro i3: nvidia_drm.modeset=1 but afterwards the system refused to start lightDM because of the following Xorg error: failed to create screen resources After some digging I have found the following message in the kernel logs that mentions a failing noveau driver, even though I haven't installed the nouveau driver. So can someone make sense of this? Mai 10 14:47:34 user1-victus kernel: nouveau 0000:01:00.0: timer: stalled at ffffffffffffffff Mai 10 14:47:34 user1-victus kernel: WARNING: CPU: 14 PID: 746 at drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmtu102.c:43 tu102_vmm_flush+0x165/0x170 [nouveau] Mai 10 14:47:34 user1-victus kernel: Modules linked in: ntfs3 uas usb_storage ccm cmac algif_hash algif_skcipher af_alg snd_ctl_led snd_soc_skl_hda_dsp snd_soc_intel_hda_dsp_common snd_soc_hdac_hdmi snd_sof_probes snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio qrtr squas> Mai 10 14:47:34 user1-victus kernel: polyval_generic ecdh_generic gf128mul videobuf2_vmalloc snd_hda_intel mac80211 fat ghash_clmulni_intel i915 nouveau libarc4 snd_intel_dspcfg videobuf2_memops sha512_ssse3 snd_intel_sdw_acpi videobuf2_v4l2 aesni_intel snd_hda_codec videobuf2_com> Mai 10 14:47:34 user1-victus kernel: CPU: 14 PID: 746 Comm: Xorg Tainted: G W 6.1.1-1-MANJARO #1 58eeef856bad441bca33a8abb39f91301fd24d8d Mai 10 14:47:34 user1-victus kernel: Hardware name: HP Victus by HP Laptop 16-d0xxx/88F8, BIOS F.22 11/28/2022 Mai 10 14:47:34 user1-victus kernel: RIP: 0010:tu102_vmm_flush+0x165/0x170 [nouveau] Mai 10 14:47:34 user1-victus kernel: Code: 8b 40 10 48 8b 78 10 48 8b 5f 50 48 85 db 75 03 48 8b 1f e8 6d 09 a9 c8 48 89 da 48 c7 c7 74 be 47 c1 48 89 c6 e8 c6 64 e8 c8 0b eb a5 e8 c2 28 ee c8 66 90 f3 0f 1e fa 0f 1f 44 00 00 ff 74 Mai 10 14:47:34 user1-victus kernel: RSP: 0018:ffffb64ac179b778 EFLAGS: 00010282 Mai 10 14:47:34 user1-victus kernel: WARNING: CPU: 14 PID: 746 at drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmtu102.c:43 tu102_vmm_flush+0x165/0x170 [nouveau] Mai 10 14:47:34 user1-victus kernel: Modules linked in: ntfs3 uas usb_storage ccm cmac algif_hash algif_skcipher af_alg snd_ctl_led snd_soc_skl_hda_dsp snd_soc_intel_hda_dsp_common snd_soc_hdac_hdmi snd_sof_probes snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio qrtr squas> Mai 10 14:47:34 user1-victus kernel: polyval_generic ecdh_generic gf128mul videobuf2_vmalloc snd_hda_intel mac80211 fat ghash_clmulni_intel i915 nouveau libarc4 snd_intel_dspcfg videobuf2_memops sha512_ssse3 snd_intel_sdw_acpi videobuf2_v4l2 aesni_intel snd_hda_codec videobuf2_com> Mai 10 14:47:34 user1-victus kernel: CPU: 14 PID: 746 Comm: Xorg Tainted: G W 6.1.1-1-MANJARO #1 58eeef856bad441bca33a8abb39f91301fd24d8d Mai 10 14:47:34 user1-victus kernel: Hardware name: HP Victus by HP Laptop 16-d0xxx/88F8, BIOS F.22 11/28/2022 Mai 10 14:47:34 user1-victus kernel: RIP: 0010:tu102_vmm_flush+0x165/0x170 [nouveau] Mai 10 14:47:34 user1-victus kernel: Code: 8b 40 10 48 8b 78 10 48 8b 5f 50 48 85 db 75 03 48 8b 1f e8 6d 09 a9 c8 48 89 da 48 c7 c7 74 be 47 c1 48 89 c6 e8 c6 64 e8 c8 0b eb a5 e8 c2 28 ee c8 66 90 f3 0f 1e fa 0f 1f 44 00 00 ff 74 Mai 10 14:47:34 user1-victus kernel: RSP: 0018:ffffb64ac179b778 EFLAGS: 00010282 Mai 10 14:47:34 user1-victus kernel: RAX: 0000000000000000 RBX: ffff98e542c9d160 RCX: 0000000000000027 Mai 10 14:47:34 user1-victus kernel: RDX: ffff98eccfba1668 RSI: 0000000000000001 RDI: ffff98eccfba1660 Mai 10 14:47:34 user1-victus kernel: RBP: ffff98e560866400 R08: 0000000000000000 R09: ffffb64ac179b600 Mai 10 14:47:34 user1-victus kernel: R10: 0000000000000003 R11: ffffffff8b4b7110 R12: 0000000005000001 Mai 10 14:47:34 user1-victus kernel: R13: ffff98e560866400 R14: ffff98e5634136c0 R15: 0000000000000000 Mai 10 14:47:34 user1-victus kernel: FS: 00007f6a3d5a2980(0000) GS:ffff98eccfb80000(0000) knlGS:0000000000000000 Mai 10 14:47:34 user1-victus kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Mai 10 14:47:34 user1-victus kernel: CR2: 00007f6a34044060 CR3: 000000012143a004 CR4: 0000000000f70ee0 Mai 10 14:47:34 user1-victus kernel: PKRU: 55555554 Mai 10 14:47:34 user1-victus kernel: Call Trace: Mai 10 14:47:34 user1-victus kernel: Mai 10 14:47:34 user1-victus kernel: nvkm_vmm_unref_pdes+0xeb/0x1f0 [nouveau b94536815bcbee6c07bf0305391ef14c5a1db60e] Mai 10 14:47:34 user1-victus kernel: nvkm_vmm_unref_pdes+0x182/0x1f0 [nouveau b94536815bcbee6c07bf0305391ef14c5a1db60e] Mai 10 14:47:34 user1-victus kernel: nvkm_vmm_unref_pdes+0x182/0x1f0 [nouveau b94536815bcbee6c07bf0305391ef14c5a1db60e] Mai 10 14:47:34 user1-victus kernel: nvkm_vmm_unref_pdes+0x182/0x1f0 [nouveau b94536815bcbee6c07bf0305391ef14c5a1db60e] Mai 10 14:47:34 user1-victus kernel: nvkm_vmm_unref_ptes+0x18c/0x250 [nouveau b94536815bcbee6c07bf0305391ef14c5a1db60e] Mai 10 14:47:34 user1-victus kernel: nvkm_vmm_iter.constprop.0+0x2a5/0x890 [nouveau b94536815bcbee6c07bf0305391ef14c5a1db60e] Mai 10 14:47:34 user1-victus kernel: ? nvkm_vmm_iter.constprop.0+0x2a5/0x890 [nouveau b94536815bcbee6c07bf0305391ef14c5a1db60e] Mai 10 14:47:34 user1-victus kernel: ? nvkm_vmm_ptes_sparse+0x1e0/0x1e0 [nouveau b94536815bcbee6c07bf0305391ef14c5a1db60e] Mai 10 14:47:34 user1-victus kernel: nvkm_vmm_put_locked+0x109/0x280 [nouveau b94536815bcbee6c07bf0305391ef14c5a1db60e] Mai 10 14:47:34 user1-victus kernel: ? nvkm_vmm_ptes_sparse+0x1e0/0x1e0 [nouveau b94536815bcbee6c07bf0305391ef14c5a1db60e] Mai 10 14:47:34 user1-victus kernel: nvkm_uvmm_mthd+0x686/0x6b0 [nouveau b94536815bcbee6c07bf0305391ef14c5a1db60e] Mai 10 14:47:34 user1-victus kernel: nvkm_ioctl+0xd9/0x180 [nouveau b94536815bcbee6c07bf0305391ef14c5a1db60e] Mai 10 14:47:34 user1-victus kernel: nvif_object_mthd+0xcc/0x200 [nouveau b94536815bcbee6c07bf0305391ef14c5a1db60e] Mai 10 14:47:34 user1-victus kernel: nvif_vmm_put+0x64/0x80 [nouveau b94536815bcbee6c07bf0305391ef14c5a1db60e] Mai 10 14:47:34 user1-victus kernel: nouveau_vma_del+0x80/0xd0 [nouveau b94536815bcbee6c07bf0305391ef14c5a1db60e] Mai 10 14:47:34 user1-victus kernel: nouveau_gem_object_close+0x1eb/0x220 [nouveau b94536815bcbee6c07bf0305391ef14c5a1db60e] Mai 10 14:47:34 user1-victus kernel: drm_gem_handle_delete+0x6a/0xd0 Mai 10 14:47:34 user1-victus kernel: ? drm_mode_destroy_dumb+0x40/0x40 Mai 10 14:47:34 user1-victus kernel: drm_ioctl_kernel+0xca/0x170 Mai 10 14:47:34 user1-victus kernel: drm_ioctl+0x1eb/0x450 Mai 10 14:47:34 user1-victus kernel: ? drm_mode_destroy_dumb+0x40/0x40 Mai 10 14:47:34 user1-victus kernel: nouveau_drm_ioctl+0x5a/0xb0 [nouveau b94536815bcbee6c07bf0305391ef14c5a1db60e] Mai 10 14:47:34 user1-victus kernel: __x64_sys_ioctl+0x91/0xd0 Mai 10 14:47:34 user1-victus kernel: do_syscall_64+0x5c/0x90 Mai 10 14:47:34 user1-victus kernel: ? syscall_exit_to_user_mode+0x1b/0x40 Mai 10 14:47:34 user1-victus kernel: ? do_syscall_64+0x6b/0x90 Mai 10 14:47:34 user1-victus kernel: ? exit_to_user_mode_prepare+0x145/0x1d0 Mai 10 14:47:34 user1-victus kernel: ? syscall_exit_to_user_mode+0x1b/0x40 Mai 10 14:47:34 user1-victus kernel: ? do_syscall_64+0x6b/0x90 Mai 10 14:47:34 user1-victus kernel: ? exc_page_fault+0x74/0x170 Mai 10 14:47:34 user1-victus kernel: entry_SYSCALL_64_after_hwframe+0x63/0xcd Mai 10 14:47:34 user1-victus kernel: RIP: 0033:0x7f6a3df23c0f Mai 10 14:47:34 user1-victus kernel: Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 c2 3d 00 f0 ff ff 77 18 48 8b 44 24 18 64 48 2b 04 25 28 00 00 Mai 10 14:47:34 user1-victus kernel: RSP: 002b:00007ffcd9c547d0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 Mai 10 14:47:34 user1-victus kernel: RAX: ffffffffffffffda RBX: 0000561a976c48d0 RCX: 00007f6a3df23c0f Mai 10 14:47:34 user1-victus kernel: RDX: 00007ffcd9c54864 RSI: 00000000c00464b4 RDI: 0000000000000015 Mai 10 14:47:34 user1-victus kernel: RBP: 00007ffcd9c54864 R08: 0000561a976da840 R09: 00007f6a3e0857a0 Mai 10 14:47:34 user1-victus kernel: R10: 0000000000000050 R11: 0000000000000246 R12: 00000000c00464b4 Mai 10 14:47:34 user1-victus kernel: R13: 0000000000000015 R14: 0000561a96eef7a0 R15: 00007f6a3d4c8a60 Mai 10 14:47:34 user1-victus kernel: Ma

I'm new to device trees, but from all the research I can't find a comprehensive tutorial on writing device trees. If concrete I have an ti sn65dsi86 and I want to connect it to an imx8 chip. Linux has already a driver for ti chip in kernel source tree under linux/drivers/gpu/drm/bridge/ti-sn65dsi86.c. This guy has written a device tree for that driver. But where the hell he got all that properties names like **ti,dp-lanes**?? I tried to derive that names from the device driver but no luck. Everything is similar but still different. Thanks!

On my **Ubuntu Linux 18.04** machine I have a whole bunch of WMA files (don't ask) which have gotten mixed up with several files from another computer that are DRM protected. The latter won't play and even crash some player software. Is there a quick-and-easy way to recurse through the entire subdirectory tree and detect which WMA files are DRM protected? I've seen solutions based on Windows XP and Powershell, but nothing for *ix. Mind you, I'm NOT looking for a (legally dubious) way to strip off the DRM protection; I just need to find out which ones are DRM protected without trying them out one by one so I can remove them. Advise to discontinue the use of WMA and switch to more sensible formats instead is unnecessary; I never use WMA if I can possibly avoid it. However, the people who pay for my meal ticket require me to support this [censored] so I have little choice.

My /proc/meminfo shows about 500 MB is allocated as Shmem. I want to get more specific figures. I found an explanation here: https://lists.kernelnewbies.org/pipermail/kernelnewbies/2013-July/008628.html > It includes tmpfs memory, SysV shared memory (from ipc/shm.c), POSIX shared memory (under /dev/shm [which is a tmpfs]), and shared anonymous mappings (from mmap of /dev/zero with MAP_SHARED: see call to shmem_zero_setup() from drivers/char/mem.c): whatever allocates pages through mm/shmem.c. > > 2-> as per the developer comments NR_SHMEM included tmpfs and GEM > > pages. what is GEM pages? > Ah yes, and the Graphics Execution Manager uses shmem for objects shared with the GPU: see use of shmem_read_mapping_page*() in drivers/gpu/drm/. I have about * 50MB in user-visible tmpfs, found with df -h -t tmpfs. * 40MB (10,000 pages of 4096 bytes) in sysvipc shared memory, found with ipcs -mu. I would like to get some more positive accounting, for what uses the 500MB! Is there a way to show total GEM allocations? (Or any other likely contributor). I expect I have some GEM allocations, since I am running a graphical desktop on intel graphics hardware. My kernel version is 4.18.16-200.fc28.x86_64 (Fedora Workstation 28).

Why do DRM render nodes in /dev/dri/renderD start their numbering from 128 while the privileged interaces in /dev/dri/card start at zero?

$ ls -al /dev/dri/
total 0
drwxr-xr-x   3 root root        100 Nov 21 07:46 .
drwxr-xr-x  23 root root       6040 Nov 22 11:09 ..
drwxr-xr-x   2 root root         80 Nov 21 07:46 by-path
crw-rw----+  1 root video  226,   0 Nov 21 07:46 card0
crw-rw----+  1 root render 226, 128 Nov 21 07:46 renderD128

When my Dell XPS 15 9570 laptop is on, the monitor plugged in the HDMI port is correctly detected. Unplugging the monitor also works as expected. However, when waking up from suspend by briefly lifting the lid open, the HDMI port is not reconfigured. Whatever was plugged at the time it was suspended is still considered connected after resuming. That means that the resolution of the previously plugged monitor is kept, causing "not supported resolution" on the new monitor if the monitors expect different resolutions. Re-connecting the new monitor fixes the issue in this case. I have not figured out exactly how, but leaving the lid open when suspended or after resuming seems to change this behavior. **How can I force the HDMI ports to be scanned again on resume?** or otherwise work around this annoying issue. ### Some more context: * Dual GPU, integrated Intel UHD 630 in use (i915) * Discrete nvidia GPU disabled, no proprietary drivers loaded * Debian 10 (buster) * Linux 4.19.0-2: nouveau.runpm=0 acpi_rev_override=1 acpi_osi=Linux nouveau.modeset=0 scsi_mod.use_blk_mq=1 mem_sleep_default=deep * Wayland 1.16, Gnome 3.30 * /sys/power/mem_sleep: s2idle [deep] ### UPDATE This keeps happening with newer BIOS and Kernel: * Debian 11 (bullseye) * Linux 5.2.0-3 * Wayland client 1.17, Gnome 3.30 * newest Dell XPS BIOS: 1.13.0

I have a full-screen Qt app running on a Raspberry Pi 3 using the "eglfs" platform. It draws using KMS/DRM and the /dev/dri/core0 GPU device. The GPU is a Broadcom VideoCore IV. I'd like to record the screen and have not been successful. The closest I've got is: 1. Using ffmpeg and the kmsgrab input device. Unfortunately ffmpeg -f kmsgrab -i - -vf 'hwdownload,format=bgr0' output.mp4 produces garbled video, as shown below. 2. Redirect Qt to the framebuffer. For example: ./my_app -platform linuxfb:fb=/dev/fb0. Then the more straight-forward ffmpeg -f fbdev -i /dev/fb0 output.mp4 works. Unfortunately linuxfb does not render features from Qt5Compat.GraphicalEffects such as layer.effect, so my buttons do not show. Given the garbled output from ffmpeg seems so close, I've tried passing various format_modifier's from [drm_fourcc.h](https://elixir.bootlin.com/linux/latest/source/include/uapi/drm/drm_fourcc.h#L380) but have not seen any difference. Surely there's a set of hwmap or format_modifier flags that will ensure the output resembles what appears on screen? For reference I'm using kernel version 5.4.83-v8 and dtoverlay=vc4-fkms-v3d. I could adjust those things if I thought it would make any difference.