On Mon, Nov 16, 2015 at 03:22:12PM -0500, Benjamin Romer wrote:
> From: Tim Sell <timothy.s...@unisys.com>
>
> Previously, we used a hack to determine the max x,y resolution of the
> visor virtual mouse: we just looked at the resolution of the
> first-registered framebuffer device, using the currently-valid assumption
> that in a Unisys s-Par guest environment the video will be provided by an
> efifb framebuffer device.
>
> This hack has been removed, by instead determining the default mouse
> resolution by looking at fields within the visor mouse channel memory,
> mouse.x_resolution and mouse.y_resolution. If these fields are 0, a
> default resolution of 1024x768 is assumed. Note that in current
> implementations, mouse.x_resolution and mouse.y_resolution are always just
> initialized to 0 by the back-end, and only 1024x768 is supported, but
> coding it this way will allow other resolutions to work in the future.
>
> Signed-off-by: Tim Sell <timothy.s...@unisys.com>
> Signed-off-by: Benjamin Romer <benjamin.ro...@unisys.com>
>
> ---
> v2: the patch was resubmitted.
> ---
> drivers/staging/unisys/visorinput/Kconfig | 2 +-
> drivers/staging/unisys/visorinput/visorinput.c | 63
> +++++++++++++++++++++-----
> 2 files changed, 52 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/staging/unisys/visorinput/Kconfig
> b/drivers/staging/unisys/visorinput/Kconfig
> index d83deb4..1c5a072 100644
> --- a/drivers/staging/unisys/visorinput/Kconfig
> +++ b/drivers/staging/unisys/visorinput/Kconfig
> @@ -4,7 +4,7 @@
>
> config UNISYS_VISORINPUT
> tristate "Unisys visorinput driver"
> - depends on UNISYSSPAR && UNISYS_VISORBUS && FB
> + depends on UNISYSSPAR && UNISYS_VISORBUS
> ---help---
> If you say Y here, you will enable the Unisys visorinput driver.
>
> diff --git a/drivers/staging/unisys/visorinput/visorinput.c
> b/drivers/staging/unisys/visorinput/visorinput.c
> index 238a132..4620a49 100644
> --- a/drivers/staging/unisys/visorinput/visorinput.c
> +++ b/drivers/staging/unisys/visorinput/visorinput.c
> @@ -47,8 +47,38 @@
> #define SPAR_MOUSE_CHANNEL_PROTOCOL_UUID_STR \
> "addf07d4-94a9-46e2-81c3-61abcdbdbd87"
>
> -#define PIXELS_ACROSS_DEFAULT 800
> -#define PIXELS_DOWN_DEFAULT 600
> +/* header of keyboard/mouse channels */
> +struct spar_input_channel_protocol {
> + struct channel_header channel_header;
> + u32 n_input_reports;
> + union {
> + struct {
> + u16 x_resolution;
> + u16 y_resolution;
If these cross the kernel/user boundry, use __u16 please.
> + } mouse;
> + struct {
> + u32 flags;
__u32?
> + } keyboard;
> + };
> +} __packed;
> +
> +#define sizeofmemb(TYPE, MEMBER) sizeof(((TYPE *)0)->MEMBER)
We really don't have this type of macro already?
> +
> +static unsigned read_input_channel_uint(struct visor_device *dev,
> + unsigned offset, unsigned size)
> +{
> + unsigned v = 0;
> +
> + if (visorbus_read_channel(dev, offset, &v, size)) {
> + dev_warn(&dev->device,
> + "failed to read channel int at offset %u\n", offset);
> + return 0;
> + }
> + return v;
> +}
> +
> +#define PIXELS_ACROSS_DEFAULT 1024
> +#define PIXELS_DOWN_DEFAULT 768
> #define KEYCODE_TABLE_BYTES 256
>
> enum visorinput_device_type {
> @@ -298,12 +328,11 @@ register_client_keyboard(void *devdata, /* opaque on
> purpose */
> }
>
> static struct input_dev *
> -register_client_mouse(void *devdata /* opaque on purpose */)
> +register_client_mouse(void *devdata /* opaque on purpose */,
Why on purpose? When is that going to be fixed?
thanks,
greg k-h
_______________________________________________
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
