Derek Foreman

Derek Foreman

About Derek Foreman

Derek Foreman is a Senior Open Source Developer with Samsung's Open Source Group, specializing in graphics work. Previously, he worked on the graphics team at an open source consultancy where his work primarily focused on hardware enablement and software optimization for embedded systems. His career started at a biomedical institute where he developed analysis and control software for medical imaging equipment.

  • Projects

    Wayland, Cairo
  • Role

    Senior Open Source Developer

Posts by Derek Foreman

  • December 21, 2017 - Derek Foreman

    The Wayland Zombie Apocalypse is Near

    Quite some time ago I received a report of a nasty Wayland bug: under certain circumstances a Wayland event was being delivered with an incorrect file descriptor. The reporter dug deeper and determined the root cause of this; it wasn’t good. When a client deletes a Wayland object, there might still be protocol events coming from the compositor destined for it (as a contrived example, I delete my keyboard object because I’m done processing keys for the day, but the user is still typing…). Once the compositor receives the delete request it knows it can’t send any more events, but due to the asynchronous nature of Wayland, there could still be some unprocessed events in the buffer destined for the recently deleted object. The Zombie Scourge This is handled by making the deleted object into a zombie, rather, THE zombie, as there is a singleton zombie object in the client […]

    Read More
  • One of the most heinous visual artifacts modern displays are capable of is tearing, on the desktop, there are two major potential sources of this: A compositor redraw during screen refresh – this leads to global artifacts such as application windows breaking up while being repositioned. Applications redrawing while the compositor is reading their content – the contents of a single window will be displayed in an indeterminate state. Under X, application redraws are tricky to do without tearing because content can be updated at any chosen time with no clear feedback as to when the compositor will read it. EFL uses some clever tricks to this end (check out the state of the art X redraw timing for yourself), but it’s difficult to get right in all cases. For a lot of people this just works, or they’re not sensitive to the issue when it doesn’t. Wayland Does Application […]

    Read More
  • I want to use this short article to point out a big problem in code that uses libdrm. This, or a variant of this, is lurking in a shocking amount of software:

    Stop doing this, it has always been a crash waiting to happen. drmEventContext is part of libdrm’s ABI and there are strict promises that the structure won’t be randomly re-ordered. However, it may grow as the need arises when new versions of libdrm offer functionality which didn’t exist before. libdrm 2.4.78 introduces another page flip handler, adding a new function pointer harmlessly at the end of the structure page_flip_handler2. It also bumps DRM_EVENT_CONTEXT_VERSION from 2 to 3, as that’s the current version of the structure in the header file. As a result, the code above crashes… sometimes. What went wrong? The Proper Way to Use drmEventContext DrmEventContext.version is intended to tell the library what version of the […]

    Read More
  • February 2, 2017 - Derek Foreman

    A Curious Wayland Bug

    Enlightenment has a slightly unconventional architecture. For many of its internal dialogues (settings, the file manager, etc.) it uses what we call “internal windows.” These are simply regular toolkit windows that use regular rendering back-ends; in the good ol’ days, this meant a connection to the X server which resulted in a render to a standard X window. In this scenario, the compositor gets the result back the same way as all X client windows, and it composites all internal and external windows together. Under Wayland, things get a bit scarier because now the compositor is the display server. Enlightenment makes a Wayland connection to itself; this gives us all manner of game winning capabilities we never had before. For example, let’s say the internal window wants to sleep and wait for a reply from the compositor (such as a released buffer to render the next frame into). We deadlock and fall down […]

    Read More
  • June 10, 2016 - Mike Blumenkrantz and Derek Foreman

    Upcoming Enlightenment Improvements: DMABuf & Teamwork V2

    E21 has been under heavy development since December of last year; the primary goals for have been to provide a more rapid release and expedite improvements in Wayland compositing to provide a much more usable experience. With the release pending, here’s a roundup of a couple recently-added Wayland features that are coming in this release. Improving Memory Sharing for Video Processing with DMABuf DMABuf is an infrastructure for sharing memory between various pieces of hardware. It’s a key technology to enable a high performance video pipeline without wasted memory copies, but its benefits aren’t limited to video processing and playback. EFL and Enlightenment now both support the Wayland DMABuf protocol, allowing clients to create buffers that can be dropped into a hardware video plane or used as a texture by the GPU, without the inherent memory copy required for wl_shm buffers. While this is good news for video players, we’ve […]

    Read More
  • Fill buffer. Attach buffer to surface. Damage surface. Commit surface. Ok, now you’ve got a picture on screen, that was easy, right? This is the (somewhat simplified) sequence of requests that’s required to show an image on screen with Wayland. A buffer is what your client draws into. A surface is what the compositor displays your buffer on. The commit operation tells the compositor it’s time to atomically perform all the surface operations you’ve been sending it.  Any surface requests prior to the commit have been buffered, and could have been requested in any order (the compositor performs them in the appropriate order during the commit). How Wayland Uses Damage to Redraw Surfaces Damage is today’s area of focus: it’s how you tell the compositor where the surface has changed since the last time it was committed. While rendering into its buffer, the client should create a list of rectangles […]

    Read More
  • April 1, 2016 - Mike Blumenkrantz and Derek Foreman

    CSS: Revolutionizing the Appearance of the WWW

    One of the most notable and enduring Linux desktop paradigms has been desktop effects: the coupling of various desktop environments with graphical niceties, also known as “eye candy.” With the advent of the XComposite extension in the mid 2000s, mainstream eye candy was taken to new levels through a small project called Compiz which used the texture from pixmap extension to apply hardware-accelerated effects to windows on the fly. From Compiz came the effect that is known throughout the Linux world as “wobbly windows” or, for many developers, “that feature we aren’t implementing.” By applying OpenGL vertex transforms to the textures created using the previously-mentioned extension, windows would appear to deform when moved and resized. This has persisted in being the benchmark for all graphical desktop effects for a decade, and numbers may not go high enough to enumerate all the users who have asked for this effect in Enlightenment […]

    Read More
  • February 9, 2016 - Derek Foreman

    WOW, Wayland Over Wire!

    A common complaint about Wayland is that it isn’t network transparent. X allows you to run an application on one computer and display its output on a different computer as long as the application doesn’t depend on certain “modern” features (such as the shared memory extension). Applications are forwarded individually and are indistinguishable from apps on the local desktop (network performance considerations aside). This is different than remote desktop protocols like VNC or RDP which provide control of an entire operating system. The Hurdles to Wayland Network Transparency Obviously, if we intend to make Wayland a replacement for X, we need to duplicate this functionality. However, some Wayland design decisions make it difficult to implement this kind of network transparency: File descriptor passing is used extensively in the protocol. For example, keymaps are passed from the compositor to the client as file descriptors; the client is supposed to mmap() the file […]

    Read More
  • January 12, 2016 - Derek Foreman

    Wayland 1.10 Sneak Preview

    Now that 2015 is deader than XFree86 and the year of the Linux desktop is finally here, I’m sure everyone’s wondering what 2016 will bring for Wayland… Sometime in mid January the 1.10 alpha release is coming, with a 1.10 release to follow in February, and this is already shaping up to be a pretty beefy release. New and Improved Here are some of the new core Wayland features that have already landed: Release requests for wl_seat – This is a step towards fixing a long standing problem. With no proper release request, it’s been impossible for the compositor to delete a wl_seat. This seems like it shouldn’t be a big deal until you consider the RDP (Remote Desktop Protocol) compositor, which creates a new seat for every login. Without a way to release seat resources completely, it effectively leaks seats. wl_surface.damage_buffer – This new request (already supported in Weston and EFL) allows […]

    Read More
  • May 26, 2015 - Derek Foreman

    When is a Keyboard Not a Keyboard?

    Much of my day-to-day work revolves around Wayland and Weston. Wayland is a protocol for communication between display servers and their clients, and Weston is a reference implementation of a Wayland display server. Simplistically (and I really can’t stress enough that this is an oversimplification), Wayland is similar to the X protocol and Weston is much like a combination of an X server and a window manager. Lately I’ve been working on Weston’s text input implementation – specifically how Weston deals with on-screen keyboards. Currently, applications directly control whether the virtual keyboard should be displayed or hidden, and I’ve been adding a way for applications to request that Weston auto-hide the virtual keyboard based on whether or not a real keyboard is present. Keyboards, Keyboards Everywhere… Wayland’s input model is based on the concept of a “seat,”  a collection of input devices that would be present in front of a single user’s seat at an office. […]

    Read More