Den 18.08.2022 01.23, skrev Noralf Trønnes: > > > 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 > I'm one step closer as I now have fbcon working, I had forgotten to add enable_tvout=1 and I had disable_fw_kms_setup=1 which disables the video= mode on the kernel commandline. modetest still fails though, after alot of printk sprinkling, I've tracked it down to the drm_mode_equal test in drm_atomic_helper_connector_tv_check(). The aspect ratios differ: [ 61.336295] drm_atomic_helper_connector_tv_check: mode->picture_aspect_ratio=1 [ 61.336301] drm_atomic_helper_connector_tv_check: &crtc_state->mode->picture_aspect_ratio=0 Noralf.
