On 10/04/17 16:00, Oleksandr Andrushchenko wrote:ah, good to know. btw, if you are about to add
Because up to now nobody is setting the Xenstore values. This is
On 04/10/2017 04:50 PM, Juergen Gross wrote:
On 10/04/17 15:44, Oleksandr Andrushchenko wrote:this is good so we can see actual width/height
Hi, Juergen!You can see the settings in sysfs.
On 03/21/2017 07:19 PM, Juergen Gross wrote:
Add a parameter for setting the resolution of xen-kbdfront in order tois this by intention that you use 0444 here?
be able to cope with a (virtual) frame buffer of arbitrary resolution.
Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
---
drivers/input/misc/xen-kbdfront.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/input/misc/xen-kbdfront.c
b/drivers/input/misc/xen-kbdfront.c
index 3900875..2df5678 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -41,6 +41,12 @@ struct xenkbd_info {
char phys[32];
};
+enum { KPARAM_WIDTH, KPARAM_HEIGHT, KPARAM_CNT };
+static int size[KPARAM_CNT] = { XENFB_WIDTH, XENFB_HEIGHT };
+module_param_array(size, int, NULL, 0444);
It means read-only, thus one cannot change these,
so what is the point of the module parameters then?
used by the pv driver
The values are settable via boot parameter.but then, if one has other values set in XenStore,
these will/may be overridden, making it inconsistent,
e.g. values loaded at start as module parameters
(*size* array) is not going to be updated on
XenbusStateInitWait/XenbusStateConnected. So, we'll
end up with wrong parameters shown via sysfs
one more question is why do we need module parameters
if the same can be read from XenStore?
something I'm planning to do for Xen 4.10.
Up to then we need a
workaround.
But you are right: The module parameters should be updated with
the values read from Xenstore.
Juergen