Den 17.08.2022 15.11, skrev Noralf Trønnes: > > > Den 17.08.2022 13.46, skrev Maxime Ripard: >> On Tue, Aug 16, 2022 at 09:35:24PM +0200, Noralf Trønnes wrote: >>> Den 16.08.2022 11.49, skrev Maxime Ripard: >>>> On Tue, Aug 16, 2022 at 11:42:20AM +0200, Noralf Trønnes wrote: >>>>> Den 16.08.2022 10.26, skrev Maxime Ripard: >>>>>> Hi, >>>>>> >>>>>> On Mon, Aug 08, 2022 at 02:44:56PM +0200, Noralf Trønnes wrote: >>>>>>> Den 29.07.2022 18.34, skrev Maxime Ripard: >>>>>>>> The TV mode property has been around for a while now to select and get the >>>>>>>> current TV mode output on an analog TV connector. >>>>>>>> >>>>>>>> Despite that property name being generic, its content isn't and has been >>>>>>>> driver-specific which makes it hard to build any generic behaviour on top >>>>>>>> of it, both in kernel and user-space. >>>>>>>> >>>>>>>> Let's create a new bitmask tv norm property, that can contain any of the >>>>>>>> analog TV standards currently supported by kernel drivers. Each driver can >>>>>>>> then pass in a bitmask of the modes it supports. >>>>>>>> >>>>>>>> We'll then be able to phase out the older tv mode property. >>>>>>>> >>>>>>>> Signed-off-by: Maxime Ripard <maxime@xxxxxxxxxx> >>>>>>>> >>> How do you test the property? I've used modetest but I can only change >>> to a tv.mode that matches the current display mode. I can't switch from >>> ntsc to pal for instance. >> >> Yep, if you want to change from PAL to NTSC, it will require a new mode. >> > > So userspace has to check tv.mode first and then create a display mode > the driver will accept if switching to a different display mode is > necessary? In other words, userspace can't discover from the kernel > which display modes a certain tv.mode/norm provides before it is > selected? If so, maybe libdrm should have some function(s) to deal with > switching between modes that require a different display mode since > knowledge about which display modes a tv.mode supports is needed before > hand. > I haven't used vc4 on Pi4 in mainline before and have finally gotten it to work. I see that the connector reports 2 modes that together fit all tv.norms so userspace doesn't have to contruct a display mode, but it does need to know which display mode belongs to a certain tv.norm. When I try to use modetest I'm unable to set a mode: pi@pi4t:~ $ modetest -M vc4 -s 45:720x480i setting mode 720x480i-29.97Hz on connectors 45, crtc 68 failed to set mode: Function not implemented The errno is misleading, modetest does a drmModeDirtyFB before checking the error returned by drmModeSetCrtc. Setting the property succeeds, but the modeset still fails: pi@pi4t:~ $ modetest -M vc4 -s 45:720x480i -w 45:"tv norm":2 setting mode 720x480i-29.97Hz on connectors 45, crtc 68 failed to set mode: Function not implemented pi@pi4t:~ $ modetest -M vc4 -c 37 tv norm: flags: bitmask values: NTSC-443=0x1 NTSC-J=0x2 NTSC-M=0x4 PAL-B=0x10 PAL-M=0x200 PAL-N=0x400 SECAM-B=0x2000 value: 2 Here's the log, can you see if there's anything obvious in there: https://gist.github.com/notro/a079498bf6b64327105752b2bafa8858 Noralf.