On Thu, 12 Sep 2019 23:26:20 -0400
Sichem Zhou wrote:
> Hi pq,
>
> Thanks for your help. Tonight I tried again with no luck, as weston_output
> has no disable signal,
Hi,
the disable signal is called destroy_signal, confusingly, for
historical reasons.
> I was trying to defer output creation until all the
> heads are connected, it didn't work, the rest of the compositor
> functionalities seems to work, it answers vt_switching and keybindings.
> Just there was no actual output.
Yes, the result of failed modesetting is likely a black or non-updated
display. You should see some failure messages in Weston's log output
though.
> I digged a bit into weston_output _enable, it does iterate through all
> heads in 'pick_crtc'. If I understand correctly, we need to create crtc for
> every heads.
No, the backend uses just one CRTC for all heads. That is the
shared-CRTC clone mode, which is the only type of clone mode currently
supported in Weston.
weston_output_enable() is too early to actually see the failure. This
function cannot actually test setting the mode, because it needs the
renderer to produce a framebuffer first. Hence, enable will succeed, a
repaint is scheduled for the new output, some time later the renderer
paints, mode set is attempted and it fails, you are left with black
screens.
This is painful, but as I explained it is not easy to improve upon.
> While this didn't work, I felt back to create additional output for new
> heads. However vI found an interesting bug(it's a weird one). If I try to
> connect to new monitors where Weston is running, the new monitor did light
> up but how image freezed (rest still working, vt_switching, etc). But If I
> try to move the cursor while connecting to new monitors, my image would not
> freeze. The same behavior exits both in Weston and my compositor (which
> based on libweston). I tried on sway, it didn't have the same issue. I
> wish I could provide more info but in this situation, I really don't know
> how to debug.
Yes, this the very reason why Weston does not claim to support
cloning with multiple CRTCs. The damage tracking is broken if any two
outputs overlap on the desktop area. The output that gets updated first
clears the damage, which means the output updating next does not
actually update the cleared region even if it should. This is also
random, because the output update order is more or less random, and
damage comes in randomly as well.
There were/are patches floating around to change the damage tracking.
The issue would be very good to fix, but it hasn't been a priority yet.
Thanks,
pq
>
> Thanks,
> Sichem
>
> Le jeu. 12 sept. 2019 03 h 50, Pekka Paalanen a
> écrit :
>
> > On Wed, 11 Sep 2019 23:58:07 -0400
> > Sichem Zhou wrote:
> >
> > > Hi wayland devs,
> > >
> > > I am trying to run multiple monitors in clone mode, which requires one
> > > output to drive multiple heads. While I can create output for every head
> > > and attach them with no problem (defaultly new output comes on the
> > right).
> > > I can't quite get clone mode to work properly.
> > >
> > > Here is steps I do right now:
> > > In the head_changed_listener:
> > > 1. Find output in the list,
> > > 2. If we don't have one, create_with_head.
> > > 3. If we found one, break, attach and disable the output.
> > > 4.set_mode(current).
> > > 5.set_scale(1).
> > > 6.set_transformation(normal).
> > > 7.enable_output.
> > >
> > > I got black screen once new monitor attached. Any steps I am missing from
> > > here? Thanks
> >
> > Hi,
> >
> > the shared-crtc clone mode which you are trying to set up completely
> > depends on hardware support. If you happen to choose two heads that the
> > hardware does not support cloning, you don't get any error back during
> > configuration (this could be regarded as a bug in libweston).
> >
> > I had the idea that you should get back some signal about the output
> > being forcefully disabled (weston_output::destroy_signal and
> > weston_compositor::output_destroyed_signal) once it tries to update the
> > first time, but now I'm not sure if I implemented that.
>
>
> > This inconvenience is because we haven't implemented testing the
> > configuration during weston_output_enable(). It is tricky to implement,
> > because we would need the renderer to produce a framebuffer before we
> > can test. It will also depend on atomic modesetting in the kernel.
> >
> > We really should handle KMS failures better and do the testing at
> > configuration stage, but it hasn't been a development priority yet.
> > Sorry.
> >
> >
> > Thanks,
> > pq
> >
pgpiXYouHzRmx.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
