Hi Jan,
On 2019/07/30, Jan Sebastian Götte wrote:
> Signed-off-by: Jan Sebastian Götte <linux@xxxxxxxxx>
> ---
> include/uapi/drm/gdepaper_drm.h | 62 +++++++++++++++++++++++++++++++++
> 1 file changed, 62 insertions(+)
> create mode 100644 include/uapi/drm/gdepaper_drm.h
>
> diff --git a/include/uapi/drm/gdepaper_drm.h b/include/uapi/drm/gdepaper_drm.h
> new file mode 100644
> index 000000000000..84ff6429bef5
> --- /dev/null
> +++ b/include/uapi/drm/gdepaper_drm.h
> @@ -0,0 +1,62 @@
> +/* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */
> +/* gdepaper_drm.h
> + *
> + * Copyright (c) 2019 Jan Sebastian Götte
> + */
> +
I'm glad to see more devices using upstream KMS interface. Usually
custom UAPI should not be needed for such devices.
Can you elaborate why this is required? Is there an open-source
userspace that uses these?
> +#ifndef _UAPI_GDEPAPER_DRM_H_
> +#define _UAPI_GDEPAPER_DRM_H_
> +
> +#include "drm.h"
> +
> +#if defined(__cplusplus)
> +extern "C" {
> +#endif
> +
> +enum drm_gdepaper_vghl_lv {
> + DRM_GDEP_PWR_VGHL_16V = 0,
> + DRM_GDEP_PWR_VGHL_15V = 1,
> + DRM_GDEP_PWR_VGHL_14V = 2,
> + DRM_GDEP_PWR_VGHL_13V = 3,
> +};
> +
> +struct gdepaper_refresh_params {
> + enum drm_gdepaper_vghl_lv vg_lv; /* gate voltage level */
>From my experience, kernel drivers aim to avoid exposing voltage control
to userspace. AFAICT exceptions are present, but generally it's a no-go.
> + __u32 vcom_sel; /* VCOM select bit according to datasheet */
> + __s32 vdh_bw_mv; /* drive high level, b/w pixel (mV) */
> + __s32 vdh_col_mv; /* drive high level, red/yellow pixel (mV) */
> + __s32 vdl_mv; /* drive low level (mV) */
> + __s32 vcom_dc_mv;
> + __u32 vcom_data_ivl_hsync; /* data ivl len in hsync periods */
> + __u32 border_data_sel; /* "vbd" in datasheet */
> + __u32 data_polarity; /* "ddx" in datasheet */
These properties look like they should live in the device-tree bindings.
> + __u32 use_otp_luts_flag; /* Use OTP LUTs */
> + __u8 lut_vcom_dc[44];
> + __u8 lut_ww[42];
> + __u8 lut_bw[42];
> + __u8 lut_bb[42];
> + __u8 lut_wb[42];
There is UAPI to manage LUT (or was it WIP with patches on the list) via
the atomic API. Is that not flexible enough for your needs?
> +};
> +
> +/* Force a full display refresh */
> +#define DRM_GDEPAPER_FORCE_FULL_REFRESH 0x00
> +#define DRM_GDEPAPER_GET_REFRESH_PARAMS 0x01
> +#define DRM_GDEPAPER_SET_REFRESH_PARAMS 0x02
> +#define DRM_GDEPAPER_SET_PARTIAL_UPDATE_EN 0x03
> +
> +#define DRM_IOCTL_GDEPAPER_FORCE_FULL_REFRESH \
> + DRM_IO(DRM_COMMAND_BASE + DRM_GDEPAPER_FORCE_FULL_REFRESH)
> +#define DRM_IOCTL_GDEPAPER_GET_REFRESH_PARAMS \
> + DRM_IOR(DRM_COMMAND_BASE + DRM_GDEPAPER_GET_REFRESH_PARAMS, \
> + struct gdepaper_refresh_params)
> +#define DRM_IOCTL_GDEPAPER_SET_REFRESH_PARAMS \
> + DRM_IOR(DRM_COMMAND_BASE + DRM_GDEPAPER_SET_REFRESH_PARAMS, \
> + struct gdepaper_refresh_params)
> +#define DRM_IOCTL_GDEPAPER_SET_PARTIAL_UPDATE_EN \
> + DRM_IOR(DRM_COMMAND_BASE + DRM_GDEPAPER_SET_PARTIAL_UPDATE_EN, __u32)
> +
Similarly to the LUT above, the atomic UAPI has support for partial
updates. The property is called FB_DAMAGE_CLIPS and there is an example
in weston how to use it see 009b3cfa6f16bb361eb54efcc7435bfede4524bc.
HTH
Emil
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
