ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
Seirdy has quit []
tzimmermann has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
Seirdy has joined #wayland
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
ahartmetz has quit [Quit: Konversation terminated!]
damjan has quit [Remote host closed the connection]
damjan has joined #wayland
soreau has quit [Read error: Connection reset by peer]
soreau has joined #wayland
zebrag has quit [Ping timeout: 480 seconds]
caveman has joined #wayland
dcz has joined #wayland
ecloud has quit [Ping timeout: 480 seconds]
ecloud has joined #wayland
pnowack has joined #wayland
eroux has joined #wayland
jgrulich has joined #wayland
rgallaispou has quit [Read error: Connection reset by peer]
caveman has quit [Ping timeout: 480 seconds]
caveman has joined #wayland
hardening has joined #wayland
danvet has joined #wayland
mvlad has joined #wayland
caveman has quit [Quit: caveman]
caveman has joined #wayland
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
<pq>
hardening, did you make sure to initialize a renderer? I think headless might default to no-op renderer, which literally does nothing, so no screenshots. Pick pixman or GL instead.
<hardening>
pq: hi, yes I've tried with gl and pixman. daniels gave the right answer, it was because there was no client doing any changes
<pq>
that's odd... asking for a screenshot should ensure an FB exists
<hardening>
I was also using the kiosk shell and switched to ivi
<pq>
I guess it's because of the optimization to not repaint anything without damage, plus taking a screenshot not causing damage (because it doesn't).
caveman has quit [Remote host closed the connection]
<hardening>
pq: yeah looks like soemthing like that
caveman has joined #wayland
<pq>
so, something to fix - probably by decoupling screenshooting from repainting
<hardening>
I guess it's also easier for the tests to have the frame generated only when some new content is there, and it also prevent timing errors
<pq>
asking for a screenshot cannot imply damage, because that would screw up damage tracking tests, and it's also logically unnecessary.
<hardening>
yeah sure
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
<pq>
no, the test suite does not deliberately control when the compositor repaints, but in practise the tests run so fast that the compositor likely doesn't repaint in the middle.
<pq>
so a screenshooting test causes damage and asks for a shot, and then some time later the compositor wakes up to repaint and deliver the shot.
rasterman has joined #wayland
tzimmermann has joined #wayland
<hardening>
exactly, so you get the screenshot done event exactly when the damage has been committed. Because if the screenshooter was not damage driven, then you could get a screenshot of the previous desktop
<hardening>
so that makes tests easier
rgallaispou has joined #wayland
<pq>
no, because the tests use the same Wayland connection to drive the test and shoot, so the compositor cannot process the shot before it has processed everything before it.
<hardening>
otherwise (if the frames were generated all the time) that would mean that you would have to do the damage, wait for a reasonable amout of time to be sure that the damage has been applied, and then screenshot
caveman has quit [Quit: caveman]
<pq>
even if we had a separate async shooting IPC, a simple wl_display.sync by the test client before shooting would be enough.
<hardening>
pq: hum yeah you're right
<pq>
hardening, would you like to file an issue about the screenshooting? I think it would be nice to fix.
<hardening>
pq: you mean an issue saying that the screenshot shall happen when requested even before a damage is there ?
<pq>
yes, taking a screeshot must not stall forever, regardless of damage. The compositor always has a framebuffer to copy from if the output is enabled.
<pq>
asking for a screenshot quite likely does schedule a repaint in libweston, but then if there is no damage, the renderer is never called, and screenshots are delivered from the renderer.
<pq>
well, not delivered because the renderer was not called
ppascher has quit [Quit: Gateway shutdown]
<pq>
so no matter what the situation, if a renderer is set up, a screenshot must complete within one or two output refresh periods.
<pq>
even if the compositor is sleeping, I might add
<pq>
as in, all outputs in power save
<pq>
that may turn out to be more work than a little fix
ppascher has joined #wayland
ppascher has quit [Read error: Connection reset by peer]