ENUM DRM_BUS_FLAGS(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

✨ enum drm_bus_flags πŸ’…

Okay bestie, welcome to the enum drm_bus_flags(9) glow-up β€” it's a Kernel API Manual moment, and this one is literally the vibe check for bus_flags info for &drm_display_info πŸ¦‹. Yes, that's the whole NAME situation, we're not wasting a single word of it.


🌸 SYNOPSIS 🌸

enum drm_bus_flags {
    DRM_BUS_FLAG_DE_LOW ,
    DRM_BUS_FLAG_DE_HIGH ,
    DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE ,
    DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE ,
    DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE ,
    DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE ,
    DRM_BUS_FLAG_DATA_MSB_TO_LSB ,
    DRM_BUS_FLAG_DATA_LSB_TO_MSB ,
    DRM_BUS_FLAG_SYNC_DRIVE_POSEDGE ,
    DRM_BUS_FLAG_SYNC_DRIVE_NEGEDGE ,
    DRM_BUS_FLAG_SYNC_SAMPLE_POSEDGE ,
    DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE ,
    DRM_BUS_FLAG_SHARP_SIGNALS

};

No cap, that's every single one of them, reproduced exactly β€” we do not edit the king πŸ‘‘.


πŸŽ€ Constants πŸŽ€

  • DRM_BUS_FLAG_DE_LOW β€” Data Enable? Active low bestie, that's the whole tea πŸ“
  • DRM_BUS_FLAG_DE_HIGH β€” Data Enable, but make it active high ✨
  • DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE β€” the data gets driven on the rising edge of the pixel clock πŸŒ…
  • DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE β€” data driven on the falling edge of the pixel clock πŸŒ™
  • DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE β€” data sampled on the rising edge of the pixel clock πŸŒ…
  • DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE β€” data sampled on the falling edge of the pixel clock πŸŒ™
  • DRM_BUS_FLAG_DATA_MSB_TO_LSB β€” data going out MSB to LSB on the bus, in that order, respectfully πŸ’…
  • DRM_BUS_FLAG_DATA_LSB_TO_MSB β€” data going out LSB to MSB on the bus, the other direction, also respectfully πŸ’…
  • DRM_BUS_FLAG_SYNC_DRIVE_POSEDGE β€” sync signals driven on the rising edge of the pixel clock πŸ”₯
  • DRM_BUS_FLAG_SYNC_DRIVE_NEGEDGE β€” sync signals driven on the falling edge of the pixel clock πŸ’€
  • DRM_BUS_FLAG_SYNC_SAMPLE_POSEDGE β€” sync signals sampled on the rising edge of the pixel clock ⭐
  • DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE β€” sync signals sampled on the falling edge of the pixel clock 🌈
  • DRM_BUS_FLAG_SHARP_SIGNALS β€” set this if the Sharp-specific signals (SPL, CLS, PS, REV) must be used πŸ‘‘ (yes, those four, exactly those four, don't come for me)

πŸ’œ Description πŸ’œ

So this enum is your one-stop shop: it defines signal polarities and clock edge information for signals on a bus, all as bitmask flags 🫢.

The clock edge info is carried by two sets of symbols β€” DRM_BUS_FLAGS_*_DRIVE_ and DRM_BUS_FLAGS_*_SAMPLE_ πŸ¦‹. Okay so which one do you use? Depends on your main character energy:

  • Describing a bus from the transmitter's point of view? Use the DRIVE_ flags πŸ“€
  • Describing it from the receiver's point of view? Use the SAMPLE_ flags πŸ“₯

And here's the iconic part: the DRIVE_ and SAMPLE_ flags alias each other, with the SAMPLE_POSEDGE and SAMPLE_NEGEDGE flags being equal to DRIVE_NEGEDGE and DRIVE_POSEDGE respectively πŸ˜­πŸ’–. Which honestly simplifies code a lot, because signals are usually sampled on the opposite edge of the driving edge β€” it's giving symmetry, it's giving efficiency.

Real talk though: transmitters and receivers may however need to take other signal timings into account to convert between driving and sample edges. Don't assume the alias does all your homework for you πŸ™ˆ.

🌟 SEE ALSO 🌟

Kernel file ./include/drm/drm_connector.h β€” and like, the whole extended friend group:

enum drm_connector_status(9), enum drm_connector_registration_state(9), enum drm_connector_tv_mode(9), struct drm_scrambling(9), struct drm_hdmi_dsc_cap(9), struct drm_hdmi_info(9), enum drm_link_status(9), enum drm_panel_orientation(9), enum drm_hdmi_broadcast_rgb(9), struct drm_monitor_range_info(9), struct drm_luminance_range_info(9), enum drm_privacy_screen_status(9), enum drm_colorspace(9), enum drm_output_color_format(9), enum drm_connector_color_format(9), struct drm_amd_vsdb_info(9), struct drm_display_info(9), struct drm_connector_tv_margins(9), struct drm_tv_connector_state(9), struct drm_connector_hdmi_infoframe(9), struct drm_connector_state(9), struct drm_connector_cec_funcs(9), struct drm_connector_infoframe_funcs(9), struct drm_connector_hdmi_funcs(9), struct drm_connector_funcs(9), struct drm_cmdline_mode(9), struct drm_connector_hdmi_audio(9), struct drm_connector_cec(9), struct drm_connector(9), drm_connector_lookup(9), drm_connector_get(9), drm_connector_put(9), drm_connector_is_unregistered(9), struct drm_tile_group(9), struct drm_connector_list_iter(9), drm_for_each_connector_iter(9), drm_connector_for_each_possible_encoder(9)

Every single one, no skips, no cap πŸ§šπŸ’œ.


✨ that's the whole page bestie, go read your kernel headers, they're literally iconic ✨

And a cute lil sign-off for the credits: this one lives in ./include/drm, stamped October 2026, and it's the enum drm_bus_flags(9) Kernel API Manual page β€” mwah πŸ’‹πŸŒΈ

πŸ“¦ where this page comes from