On 27/01/17 17:10, Dmitry Torokhov wrote:And you may also end up with thin Dom0 w/o udev at all...
On January 27, 2017 12:31:19 AM PST, Juergen Gross <jgross@xxxxxxxx> wrote:Hmm, is this a good idea?
On 27/01/17 09:26, Oleksandr Andrushchenko wrote:How about you do the axis adjustment from userspace (udev rule), and leave kernel as is?
On 01/27/2017 10:14 AM, Juergen Gross wrote:pointing
On 27/01/17 08:53, Oleksandr Andrushchenko wrote:
On 01/27/2017 09:46 AM, Juergen Gross wrote:
On 27/01/17 08:21, Oleksandr Andrushchenko wrote:
On 01/27/2017 09:12 AM, Juergen Gross wrote:
Instead of using the default resolution of 800*600 for the
(virtual)device of xen-kbdfront try to read the resolution of the
Torokhov)framebuffer device. Use the default as fallback only.
Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
---
V2: get framebuffer resolution only if CONFIG_FB (Dmitry
void---
drivers/input/misc/xen-kbdfront.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/input/misc/xen-kbdfront.c
b/drivers/input/misc/xen-kbdfront.c
index 3900875..3aae9b4 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -16,6 +16,7 @@
#include <linux/kernel.h>
#include <linux/errno.h>
#include <linux/module.h>
+#include <linux/fb.h>
#include <linux/input.h>
#include <linux/slab.h>
@@ -108,7 +109,7 @@ static irqreturn_t input_handler(int rq,
xenbus_device*dev_id)
static int xenkbd_probe(struct xenbus_device *dev,
const struct xenbus_device_id *id)
{
- int ret, i;
+ int ret, i, width, height;
unsigned int abs;
struct xenkbd_info *info;
struct input_dev *kbd, *ptr;
@@ -173,9 +174,17 @@ static int xenkbd_probe(struct
getHmm, so you think I should add a call to fb_register_client() to*dev,This still will not help if FB gets registered after kbd+ptr
ptr->id.product = 0xfffe;
if (abs) {
+ width = XENFB_WIDTH;
+ height = XENFB_HEIGHT;
+#ifdef CONFIG_FB
+ if (registered_fb[0]) {
deviceagreeOkay, that's not worse than today.events for new registered framebuffer devices?yes, but also pay attention to CONFIG_FB_NOTIFY: you may still
end up w/o notification.
This would probably work. I'll have a try.My bigger concern here is that we try to tie keyboard and pointer
Thanks,
Juergen
andto the framebuffer. IMO, these are independent parts of the system
framebufferthe relation
depends on the use-case. One can have graphics enabled w/o
defaultsat all, e.g.Again: that's a use case which will work as today. The current
DRM/KMS + OpenGLES + Weston + kbd + ptr...
offare being used.
The question is whether we should add a module parameter switching
Fine.the automatic adaption of the resolution as there might be use casesI think for those who doesn't want this resolution there is
where we don't want this feature.
still a possibility to change it on backend's XenbusStateConnected
So, no need for module parameter, IMO
I'll send V3 soon.
I'd need a udev rule to trigger when either the pointing device or a
new frame buffer is showing up. In both cases I need to read the
geometry of the frame buffer (in case it exists) and set the geometry
of the pointing device (in case it exists) to the same values. This
seems to be much more complicated than the required changes in the
driver.
I could be wrong, of course, especially as I'm no expert in writing
udev rules. :-)
Juergen