From May 25 to May 29, 2026, the Linux Display Next Hackfest convened in the vibrant city of Nice, France, just after Embedded Recipes 2026. This time the event was hosted by Collabora. This annual gathering has established itself as a cornerstone event for the Linux Graphics community, bringing together a dynamic mix of kernel developers, compositor maintainers and hardware vendor to push the boundaries of Linux Graphics innovation.

For the third consecutive year, Bootlin was proud to participate, this time with a team of three: Köry Maincent, Luca Ceresoli, and Louis Chauvet. Our involvement in this event is more than just attendance, that’s a way to build a bridge between our customers needs and the Linux community.

This year’s Hackfest was particularly rich in discussions, covering a broad spectrum of topics such as MST bandwidth allocation, Native DisplayID, tiled monitors, color operations, Variable Refresh Rate, and High Dynamic Range. We presented four critical areas for which we aim at bringing improved upstream support, to meet the needs of our customers:

• Link training and firmware update issues on DisplayPort
• DRM bridge hotplug support
• Backlight configuration
• DisplayPort status properties

Link training and firmware update conflicts [slides]

Last year, a critical issue emerged involving conflicts between DisplayPort link training and firmware updates. Specifically, if userspace initiates a firmware upgrade via /dev/drm_dp_aux* while the kernel simultaneously starts link training, the firmware update can fail. This leaves the device in an unstable state, and the link training process may never complete successfully.

To prevent this race condition, mutual exclusion is essential. Our initial proposal introduced a lock mechanism tied to the open/close operations of drm-dp-aux and link training. Technically, this works:

• If the file is open in userspace, link training is blocked.
• If link training is active, userspace cannot access the file.

However, this approach revealed a significant limitation: libddc, used by compositors to control external display backlighting, opens the file at the start of a session and closes it only at the end. This effectively prevents link training from ever occurring, which is unacceptable.

After further discussion, Dmitry Baryshkov proposed a more elegant solution: adding an ioctl to explicitly lock the file. This approach shifts the responsibility to userspace (e.g., fwupd) to manage the lock, ensuring compatibility with existing systems while avoiding breaking older userspace implementations.

DRM Bridge hotplug [slides]

Luca presented his recent proposal to make DRM bridges hot-pluggable, which comes after a lot of work to make bridges refcounted and other preparation work.

The discussion was mostly with Dmitry Baryshkov (major contributor to the drm_bridge_connector code) and a bit with Paul Kocialkowski and others.

Luca’s proposal to extend the drm_bridge_connector to implement hotplug, and the general architecture proposed, raised no objection.

There were various implementation aspects discussed:

• Dmitry rightfully pointed out the proposed requirement that bridge drivers return -EPROBE_DEFER when the next bridge is not present is a risky one: some drivers might just defer during their probe, potentially generating deferral loops.
  • The main alternative discussed is that bridge drivers expose info about how to find the next bridge (the fwnode perhaps) using a new API, keeping the existing APIs untouched. Maybe they could also expose the previous driver fwnode, for consistency, even though it currently seems unnecessary.
  • There are various options about how such new API should look like and when it should be triggered:
    • during registration, e.g. by drm_bridge_add(), unless it’s too early for some complex drivers
    • at bridge attach time, unless it is too late
    • as a new callback (to be called when?)
  • In all cases this new API would be a superset of the .is_tail callback proposed in patch 30, which would then become unnecessary.
• Dmitry asked whether all the attach chain could be entirely moved to the drm_bridge_connector for drivers using it. Worth investigating.
• The drm_atomic_shutdown() added by patch 25 is wrong, it would stop streaming on all outputs on the card. But it is probably unnecessary, just removing the connector should be enough.

Overall the discussion was very positive and it gave Luca the indication that the overall approach is correct, meaning he can now concentrate on fixing the implementation details as discussed.

Backlight configuration

Mario Limonciello from AMD presented his ongoing work on exposing backlight properties, a feature requested by our customers to help compositors in two main ways: making it easier to associate backlights with their respective displays, and enabling synchronization between picture and backlight, which can be used for effects like HDR emulation.

During the discussions, several challenges were identified. The first is the lack of standardization for backlight value meaning, including units and response curves. The second challenge is the inconsistent range of values, where zero can mean either the minimum brightness or completely off. Finally, it was noted that backlight is not always synchronized with a frame, which means an asynchronous solution must be maintained to handle these cases.

To address these issues, several solutions were proposed. Compositors will need to parse DisplayID to gather the necessary details that the kernel cannot provide. For the range inconsistency, it was suggested to start the range at 1 by default, with a whitelist for backlights that can safely start at 0.

The discussion was overall productive and provided clear direction for refining the implementation details moving forward.

DisplayPort Status Properties [slides]

Köry presented his recent proposal to add support for generic DRM properties for surfacing DisplayPort link capabilities and parameters to userspace. This work aims at providing better visibility into the DisplayPort connection state, enabling more intelligent decision-making at the userspace level.

This development addresses several important userspace needs:

• Intelligent connector selection: Guide users to select the most suitable DisplayPort connector for their needs. For example, if you have a USB-C hub with lesser capabilities than your computer’s native DisplayPort connector (such as HBR2 versus HBR3 support), the system could recommend connecting high-resolution displays directly to the computer’s port instead of through the hub to ensure optimal performance.
• Optimized MST configurations: In Multi-Stream Transport scenarios where multiple displays are connected through a hub, bandwidth management is critical. If userspace knows the negotiated link parameters, it can make smarter decisions when allocating resolutions and refresh rates to each downstream sink based on the total available link bandwidth between the source and the hub.

Several implementation aspects were discussed:

• API choice: Should we use DRM properties or sysfs? While both are valid APIs, the community prefers to avoid introducing too many new DRM properties. They asked us to change the implementation to use sysfs instead. However, during the upstream process, if DRM properties prove more appropriate, we could revisit that approach.
• Scope of information: The initial implementation only reported source capabilities and the negotiated link parameters. The community believes it would be valuable to also expose sink capabilities (available from the DisplayPort Configuration Data or DPCD) and the maximum achievable link parameters between a specific source and sink pair. This would give userspace a complete picture of what’s possible, not just what’s currently active.

Overall, the discussion was very positive and gave Köry confirmation that the fundamental approach is sound. He can now focus on refining the implementation details as discussed, particularly migrating to sysfs and expanding the scope to include sink capabilities.

Conclusion

Just like the previous editions, we were very happy to be invited and to participate in the Linux Display Next Hackfest 2026. It was another great opportunity to reconnect with the community, exchange ideas, and explore the latest advancements in Linux Graphics. The event was superbly organized, with lively discussions, hands-on hacking, and—of course—plenty of time to relax and socialize over drinks.

This year’s edition left us even more inspired, and we’re already looking forward to next year’s gathering!