Wayland/weston opens files in suspend/resume
Hi, I have custom iMX6 based HW running image generated with Yocto 2.4 (Wayland 2.0.0) and Linux kernel 4.1.x that I've been testing with suspend/resume cycles. I noticed that after each suspend/resume cycle open file count increases. In my testing I got around 490 suspend/resume cycles until libwayland gave error that there is too many open files. -- [14:29:52.385] libwayland: dup failed: Too many open files [14:29:52.385] caught signal: 6 The Wayland connection broke. Did the Wayland compositor die? -- Looking at the lsof output after around 60 suspend/resume cycles I can see that for example this file appears 60 more times: -- weston 921root 11u CHR 29,0 0t0 5323 /dev/fb0 -- The 11u part changes, but other parts are same. First time there is 11u and 13u but later it goes all the way to 93u (some numbers are missing). Also my QT application running when suspending keeps keeping these kinds of files open which I assume (I may be wrong) because the weston. -- qtapplicat 929 965 root 11u REG 0,1848097 12272 /run/user/root/weston-shared-24Zz9a (deleted) -- I know that the Weston is quite old since I think 4.0.0 has already come out,but is there any known bug that causes this? I did a search, but couldn't find any. I know it's rare to need suspend/resume over 400 times without cutting power at some point, but I'm sure there'll be that one customer that does it. -Teemu K ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland/weston opens files in suspend/resume
On Wed, Aug 22, 2018 at 12:51 PM Pekka Paalanen wrote: > > On Wed, 22 Aug 2018 12:18:00 +0300 > Teemu K wrote: > > > Hi, > > > > I have custom iMX6 based HW running image generated with Yocto 2.4 > > (Wayland 2.0.0) and Linux kernel 4.1.x that I've been testing with > > suspend/resume cycles. > > > > I noticed that after each suspend/resume cycle open file count > > increases. In my testing I got around 490 suspend/resume cycles until > > libwayland gave error that there is too many open files. > > -- > > [14:29:52.385] libwayland: dup failed: Too many open files > > [14:29:52.385] caught signal: 6 > > The Wayland connection broke. Did the Wayland compositor die? > > -- > > Looking at the lsof output after around 60 suspend/resume cycles I can > > see that for example this file appears 60 more times: > > -- > > weston 921root 11u CHR 29,0 0t0 > > 5323 /dev/fb0 > > -- > > > > The 11u part changes, but other parts are same. First time there is > > 11u and 13u but later it goes all the way to 93u (some numbers are > > missing). > > > > Also my QT application running when suspending keeps keeping these > > kinds of files open which I assume (I may be wrong) because the > > weston. > > > > -- > > qtapplicat 929 965 root 11u REG 0,1848097 > > 12272 /run/user/root/weston-shared-24Zz9a (deleted) > > -- > > > > I know that the Weston is quite old since I think 4.0.0 has already > > come out,but is there any known bug that causes this? I did a search, > > but couldn't find any. I know it's rare to need suspend/resume over > > 400 times without cutting power at some point, but I'm sure there'll > > be that one customer that does it. > > Hi, > > I hope it would be more correct to say it's rare to see anyone care > about the fbdev backend. ;-) > > Leaking file descriptors to /dev/fb0 over suspend/resume does not > surprise me, but I don't recall any bug reports or fixes exactly to that > effect. Also the fbdev device handling has been changed since Weston > 2.0.0, so it's possible it might be already fixed. Or maybe not. I seem > to recall that VT switching with the fbdev-backend has been broken for > years. > > I would not expect Weston to ever have made a dozen open file > descriptors to /dev/fb0. Are you sure you are not using proprietary EGL > drivers with the fbdev-backend? If you use EGL with fbdev, then we > certainly cannot help you. > > If you found fd leaking with the DRM-backend and a more recent release, > there would be much more interest in it. However, I suppose we do still > take patches to fix bugs in the fbdev-backend for master branch, even > though we probably reject any feature additions (complicated ones at > least). > > weston-shared-* file might be a keymap, nothing else comes to mind that > Weston would allocate, and I hope Qt does not use weston's name for its > own stuff. Hi, Well, since it's i.MX6 and NXP (still) doesn't provide proper video driver so proprietary EGL driver is being used. I think they even made their own fork for Weston 2.0.0 onward that they can keep using their old driver instead fixing it to the way Wayland wants it. I did try Etnaviv opensource graphics driver, but I couldn't get it working even with the newer kernel so I'm stuck with the old driver. But it seems that as I suspected it's not so much Wayland problem, but the driver issue. -Teemu ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Touchscreen calibration matrix changes
Hi,
I'm trying to get touch calibration working on Wayland/Weston for
resistive touch. I can get the calibration points and calculate
calibration matrix values, but when I call
libinput_device_config_calibration_set_matrix and then read it back it
would seem that the matrix is changed, but the actual touchscreen does
not indicate so. Ie. if I calibrate the touch clearly wrong it still
behaves like it would have been calibrated perfectly.
If I set the same values to udev rule like this:
ATTRS{name}=="tsc2007", ENV{LIBINPUT_CALIBRATION_MATRIX}="1.29342,
-0.0223598, -0.135092, -0.0272545, -1.11435, 1.04368"
They get taken in use and I can read those values as default values
with libinput_device_config_calibration_get_default_matrix - function.
Is there something else that needs to be done to get the updated
matrix taken in use or is there known issue with Wayland/Weston given
that it is quite old version Wayland 1.17.0/Weston 6.0.1.
Unfortunately I'm stuck with those versions for now.
Thanks.
t. TeemuK
Re: Touchscreen calibration matrix changes
On Tue, Apr 5, 2022 at 5:21 PM Pekka Paalanen wrote:
>
> On Tue, 29 Mar 2022 15:31:59 +0300
> Teemu K wrote:
>
> > Hi,
> >
> > I'm trying to get touch calibration working on Wayland/Weston for
> > resistive touch. I can get the calibration points and calculate
> > calibration matrix values, but when I call
> > libinput_device_config_calibration_set_matrix and then read it back it
> > would seem that the matrix is changed, but the actual touchscreen does
> > not indicate so. Ie. if I calibrate the touch clearly wrong it still
> > behaves like it would have been calibrated perfectly.
>
> Hi,
>
> what exactly do you mean by "when I call
> libinput_device_config_calibration_set_matrix", what is "I" there?
By "I" I mean the application.
> > If I set the same values to udev rule like this:
> > ATTRS{name}=="tsc2007", ENV{LIBINPUT_CALIBRATION_MATRIX}="1.29342,
> > -0.0223598, -0.135092, -0.0272545, -1.11435, 1.04368"
> >
> > They get taken in use and I can read those values as default values
> > with libinput_device_config_calibration_get_default_matrix - function.
>
> That's right.
>
> > Is there something else that needs to be done to get the updated
> > matrix taken in use or is there known issue with Wayland/Weston given
> > that it is quite old version Wayland 1.17.0/Weston 6.0.1.
> > Unfortunately I'm stuck with those versions for now.
>
> I'm not sure what problem you have. The udev rule works, right?
Yeah, but the problem was replacing those defaults with the calibrated
values with that ibinput_device_config_calibration_set_matrix -
function.
> Or do you mean updating the calibration matrix while Weston is already
> running?
>
> Did you write a new program that simply calls
> libinput_device_config_calibration_set_matrix() and then expect Weston
> to pick that up when you run it?
Weston is already running and I'm trying to set a new matrix in use
for Weston. Is that not what the
ibinput_device_config_calibration_set_matrix - function is meant for?
> If so, then libinput just does not work that way. There is no persistent
> configuration in libinput, and any setting you make is local in the
> in-memory libinput data structure. The udev rules are the persistent
> configuration. That's why e.g. calibration_helper option exists in
> weston.ini, so that you could have your own way of storing the
> calibration in udev rules.
This is not the issue. I'm very well aware that there is no persistent
storage in libinput and I'm not trying to use it as such. I'm trying
to set a new matrix when Weston is already running.
But I ended up copying the implementation from weston-touch-calibrator
as you mentioned instead and it worked so this issue is solved.
Thanks.
-TeemuK
> It looks like clients/touch-calibrator.c existed already in Weston
> 6.0.0. It's a ready-made calibration tool that computes
> LIBINPUT_CALIBRATION_MATRIX values, and uploads those to Weston. You
> need weston.ini option touchscreen_calibrator=true to make it work, and
> the calibration_helper option to save the calibration persistent. These
> are described in the weston.ini man page, and there is an example
> script at
> https://gitlab.freedesktop.org/wayland/weston/-/blob/main/doc/scripts/calibration-helper.bash
>
> The option touchscreen_calibrator=true exposes a Wayland extension that
> allows both getting raw touch coordinates and uploading a new
> calibration matrix to Weston. This is the only way to update the matrix
> without restarting Weston.
>
>
> Thanks,
> pq
Re: Touchscreen calibration matrix changes
Persistent storage was never the problem. Issue was getting the
non-default values in use, but it has now been sorted.
-TeemuK
On Wed, Apr 6, 2022 at 7:58 AM Peter Hutterer wrote:
>
> On Wed, Apr 06, 2022 at 06:02:22AM +0300, Teemu K wrote:
> > On Tue, Apr 5, 2022 at 5:21 PM Pekka Paalanen wrote:
> > >
> > > On Tue, 29 Mar 2022 15:31:59 +0300
> > > Teemu K wrote:
> > >
> > > > Hi,
> > > >
> > > > I'm trying to get touch calibration working on Wayland/Weston for
> > > > resistive touch. I can get the calibration points and calculate
> > > > calibration matrix values, but when I call
> > > > libinput_device_config_calibration_set_matrix and then read it back it
> > > > would seem that the matrix is changed, but the actual touchscreen does
> > > > not indicate so. Ie. if I calibrate the touch clearly wrong it still
> > > > behaves like it would have been calibrated perfectly.
> > >
> > > Hi,
> > >
> > > what exactly do you mean by "when I call
> > > libinput_device_config_calibration_set_matrix", what is "I" there?
> > By "I" I mean the application.
> >
> > > > If I set the same values to udev rule like this:
> > > > ATTRS{name}=="tsc2007", ENV{LIBINPUT_CALIBRATION_MATRIX}="1.29342,
> > > > -0.0223598, -0.135092, -0.0272545, -1.11435, 1.04368"
> > > >
> > > > They get taken in use and I can read those values as default values
> > > > with libinput_device_config_calibration_get_default_matrix - function.
> > >
> > > That's right.
> > >
> > > > Is there something else that needs to be done to get the updated
> > > > matrix taken in use or is there known issue with Wayland/Weston given
> > > > that it is quite old version Wayland 1.17.0/Weston 6.0.1.
> > > > Unfortunately I'm stuck with those versions for now.
> > >
> > > I'm not sure what problem you have. The udev rule works, right?
> > Yeah, but the problem was replacing those defaults with the calibrated
> > values with that ibinput_device_config_calibration_set_matrix -
> > function.
> >
> > > Or do you mean updating the calibration matrix while Weston is already
> > > running?
> > >
> > > Did you write a new program that simply calls
> > > libinput_device_config_calibration_set_matrix() and then expect Weston
> > > to pick that up when you run it?
> > Weston is already running and I'm trying to set a new matrix in use
> > for Weston. Is that not what the
> > ibinput_device_config_calibration_set_matrix - function is meant for?
> >
> > > If so, then libinput just does not work that way. There is no persistent
> > > configuration in libinput, and any setting you make is local in the
> > > in-memory libinput data structure. The udev rules are the persistent
> > > configuration. That's why e.g. calibration_helper option exists in
> > > weston.ini, so that you could have your own way of storing the
> > > calibration in udev rules.
> > This is not the issue. I'm very well aware that there is no persistent
> > storage in libinput and I'm not trying to use it as such. I'm trying
> > to set a new matrix when Weston is already running.
>
> The issue here is less whether libinput has persistent storage, the issue is
> that you do not have access to the libinput context that the compositor uses.
> https://wayland.freedesktop.org/libinput/doc/latest/faqs.html#can-i-write-a-program-to-make-libinput-do-foo
>
> The only way around this is to use compositor-provided knobs that *the
> compositor* then converts into libinput configuration calls. Like the weston
> touch protocol that you have found now.
>
> Cheers,
> Peter
>
> >
> > But I ended up copying the implementation from weston-touch-calibrator
> > as you mentioned instead and it worked so this issue is solved.
> >
> > Thanks.
> >
> > -TeemuK
> >
> > > It looks like clients/touch-calibrator.c existed already in Weston
> > > 6.0.0. It's a ready-made calibration tool that computes
> > > LIBINPUT_CALIBRATION_MATRIX values, and uploads those to Weston. You
> > > need weston.ini option touchscreen_calibrator=true to make it work, and
> > > the calibration_helper option to save the calibration persistent. These
> > > are described in the weston.ini man page, and there is an example
> > > script at
> > > https://gitlab.freedesktop.org/wayland/weston/-/blob/main/doc/scripts/calibration-helper.bash
> > >
> > > The option touchscreen_calibrator=true exposes a Wayland extension that
> > > allows both getting raw touch coordinates and uploading a new
> > > calibration matrix to Weston. This is the only way to update the matrix
> > > without restarting Weston.
> > >
> > >
> > > Thanks,
> > > pq
