<html><body><div>On 02 Oct, 2015,at 09:13 AM, Pekka Paalanen <ppaalanen@gmail.com> wrote:<br><br><div><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><span class="body-text-content">However, for special use cases like yours, there are alternatives that<br>would work more reliably, but also require more work to implement:<br><br>- fullscreen shell; This is a replacement to desktop shell, which means<br> you cannot run desktop apps on it, unless they (the toolkit they use)<br> specifically implements support for it. This is primarily meant for<br> running another Wayland compositor on Weston, using Wayland as<br> the hardware abstraction.<br><br>- Not using a display server at all. This is the most reliable way<br> which gives you all the control without anything else meddling with<br> your program and direct feedback from the kernel driver on what<br> really is going on, but the downside is that you get to implement<br> DRM/KMS usage and the whole input handling yourself. The good thing<br> is that nowadays you don't need to use any hardware or driver<br> specific APIs to do this (the xf86-video-* driver component is not<br> necessary anymore).<br><br>Btw. I don't think SDL2 exposes any timing interfaces, does it? So if<br>you care about exact timings and knowing when your frame was presented,<br>you'd have to use something else. I have a vague recollection SDL2<br>would not even be able to tell you that the display server has accepted<br>your frame (the frame callback in Wayland) which we normally use for<br>driving the rendering loop in an app to avoid wasted rendering.</span></div></div></blockquote><span> </span><br><div>Thank you for the explanation. Using desktop should not really be neccessary for my use, since this is a dedicated tool.<br>I will try one of the other options.<br><br>Thanks,<br>-Robert<br></div><br></div></div></body></html>