Touch cause Cintiq Pro 32 Touch to randomly lose pen input unless disable with physical button #146
Comments
|
Same here. I use Cintiq Pro 32 on ThinkPad X1 Carbon gen3, with Arch Linux. |
|
@tattsan can you let us know if you are also using one of the China models? If not, are you also using USB-C or using the USB-A / DisplayPort connections instead? |
|
My Cintiq Pro 32 has DisplayPort, HDMI, USB-A, USB-C ports. I am using USB-A / DisplayPort connection. I don't need touch function, so I always disable it by touch key panel. But every time I start the tablet up, it is enabled;-) |
|
I have a similiar problem on my Wacom Intuos Pro S when using bluetooth. I am resting my palm on the tablet while having the pen close to the surface and sometimes it recognizes touch instead of the pen. It sounds similiar to the problem described here. It does not occur when I am using it wired with usb-c. Up-to-date input-wacom-dkms from git repository here and am on Arch Linux with Kernel 5.5.4 |
|
@dantempla No, It's a totally different thing. You situation is exactly how the device should normally behave. Palm rejection depends on touch sensitivity and stylus height, human cannot sense or control how high exactly the stylus is off the surface so the pen goes in or out the range as your hands moving. It'll never be reliable. I guess the reason you found it happens more on Bluetooth is either because the stylus maximum height range is lower on Bluetooth mode, or because in BT mode the report rate is so low that the stylus input events went missing in a few ms and the driver switched to use touch input event. The bug we are discussing here, does not require the hand or the pen to be placed on the surface to trigger. It happens randomly as long as the touch function is ON. When it happens, the pen input is completely dead, and it'll stay dead until it randomly decided to come back. |
|
@tysontan Oh, okay. I understand and thank you for the guesses on my problem, they sound reasonable. The problem does not occur on Windows 10, so I guess it must be a software thing. |
|
I used the scripts from @jigpu (https://gist.githubusercontent.com/jigpu/b7b47e4bede584cec8562f666fd84af4/raw/af36c0a0fc2c019750472443369915ad7ea97737/capture.sh) to capture a log when the bug was triggered. On Arch you need to install the foloowing package to run the script:
During the capture, pen input stay dead for most of the time until it got back to life in the last few seconds. Here is the captured file: @tattsan maybe you can also attempt the capture so we have more data? Thanks! |
|
Additionally, I found out that even after turning OFF Touch by using the physical button, the pen input would still die at rare occasions. It's much less frequent than leaving the Touch is ON though. Now my Linux kernel is 5.5.2. But probably unrelated. It might just be me drawing all day recently, and as a result, easier to notice when the pen input suddenly dies. |
|
Thanks @tysontan ! I will try that script. |
|
Here is my log: I waited until the pen is recognized again, but the pen did't came back. |
|
The above record_1582354444.*.log are logs of the Pen device. |
|
Thanks @tysontan. Looks like we're still getting valid data from the tablet at the beginning of the log, but no events are leaving the kernel. This smells a lot like touch state corruption, which could make the kernel accidentally enable arbitration when it shouldn't. I know I wrote a script to find corruption in the touch logs, but I'm not sure where I left it... Hopefully I don't have to end up re-writing it... |
|
Made a bit of progress on this. I've built a tool to monitor the status of multitouch devices to see when the touch state gets corrupted and used this to find a minimal HID recording which triggers the bug (below). Together, this has allowed me to bisect the problem to commit 13b5f03 The issue seems to be with how we're counting the number of expected touches, and this commit definitely changes that behavior, so I'll see if I can understand what is wrong. |
jigpu
added a commit
to jigpu/input-wacom
that referenced
this issue
Mar 23, 2020
… per collection basis" This reverts commit 15893fa40109f5e7c67eeb8da62267d0fdf0be9d. The referenced commit broke pen and touch input for a variety of devices such as the Cintiq Pro 32. Affected devices may appear to work normally for a short amount of time, but eventually loose track of actual touch state and can leave touch arbitration enabled which prevents the pen from working. The commit is not itself required for any currently-available Bluetooth device, and so we revert it to correct the behavior of broken devices. This breakage occurs due to a mismatch between the order of collections and the order of usages on some devices. This commit tries to read the contact count before processing events, but will fail if the contact count does not occur prior to the first logical finger collection. This is the case for devices like the Cintiq Pro 32 which place the contact count at the very end of the report. Without the contact count set, touches will only be partially processed. The `wacom_wac_finger_slot` function will not open any slots since the number of contacts seen is greater than the expectation of 0, but we will still end up calling `input_mt_sync_frame` for each finger anyway. This can cause problems for userspace separate from the issue currently taking place in the kernel. Only once all of the individual finger collections have been processed do we finally get to the enclosing collection which contains the contact count. The value ends up being used for the *next* report, however. This delayed use of the contact count can cause the driver to loose track of the actual touch state and believe that there are contacts down when there aren't. This leaves touch arbitration enabled and prevents the pen from working. It can also cause userspace to incorrectly treat single- finger input as gestures. Ref: linuxwacom#146 Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com> Fixes: 15893fa40109 ("HID: wacom: generic: read the number of expected touches on a per collection basis") Cc: stable@vger.kernel.org # 5.3+
|
I've spent a long time looking at this issue and I think the best way forward is to revert the buggy commit and then potentially revisit the feature it was introducing at a later time. I've pushed up a new branch to my repository which contains the revert as well as another touch-related fix. Follow the instructions to build the driver. Instead of downloading the latest driver release, however, run the following two commands to check out the branch with the fix: Please let me know if this branch fixes the behavior for you. I'll be submitting these fixes upstream once I get the green light from you and after finishing my own final tests. |
jigpu
added a commit
to jigpu/input-wacom
that referenced
this issue
Mar 23, 2020
… per collection basis" This reverts commit 15893fa40109f5e7c67eeb8da62267d0fdf0be9d. The referenced commit broke pen and touch input for a variety of devices such as the Cintiq Pro 32. Affected devices may appear to work normally for a short amount of time, but eventually loose track of actual touch state and can leave touch arbitration enabled which prevents the pen from working. The commit is not itself required for any currently-available Bluetooth device, and so we revert it to correct the behavior of broken devices. This breakage occurs due to a mismatch between the order of collections and the order of usages on some devices. This commit tries to read the contact count before processing events, but will fail if the contact count does not occur prior to the first logical finger collection. This is the case for devices like the Cintiq Pro 32 which place the contact count at the very end of the report. Without the contact count set, touches will only be partially processed. The `wacom_wac_finger_slot` function will not open any slots since the number of contacts seen is greater than the expectation of 0, but we will still end up calling `input_mt_sync_frame` for each finger anyway. This can cause problems for userspace separate from the issue currently taking place in the kernel. Only once all of the individual finger collections have been processed do we finally get to the enclosing collection which contains the contact count. The value ends up being used for the *next* report, however. This delayed use of the contact count can cause the driver to loose track of the actual touch state and believe that there are contacts down when there aren't. This leaves touch arbitration enabled and prevents the pen from working. It can also cause userspace to incorrectly treat single- finger input as gestures. Ref: linuxwacom#146 Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com> Reviewed-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com> Fixes: 15893fa40109 ("HID: wacom: generic: read the number of expected touches on a per collection basis") Cc: stable@vger.kernel.org # 5.3+
|
Thank you Jason! I'm rushing some tasks at the moment. I will test it a bit later and report back to you. |
|
Thank you so mutch. I built and installed the module yesterday, with no trouble for now. |
|
Thank you tattsan! I've been testing the patch today as well. So far I haven't noticed any problem. Please give me a few more days so that I can be absolutely sure of it. |
|
After using the patched version heavily for a few days, I never noticed any problem. I think it's safe. Thank you again jigpu! |
|
I've also been with no troubles too. Thank you! |
ruscur
pushed a commit
to ruscur/linux
that referenced
this issue
Apr 17, 2020
… per collection basis" This reverts commit 15893fa. The referenced commit broke pen and touch input for a variety of devices such as the Cintiq Pro 32. Affected devices may appear to work normally for a short amount of time, but eventually loose track of actual touch state and can leave touch arbitration enabled which prevents the pen from working. The commit is not itself required for any currently-available Bluetooth device, and so we revert it to correct the behavior of broken devices. This breakage occurs due to a mismatch between the order of collections and the order of usages on some devices. This commit tries to read the contact count before processing events, but will fail if the contact count does not occur prior to the first logical finger collection. This is the case for devices like the Cintiq Pro 32 which place the contact count at the very end of the report. Without the contact count set, touches will only be partially processed. The `wacom_wac_finger_slot` function will not open any slots since the number of contacts seen is greater than the expectation of 0, but we will still end up calling `input_mt_sync_frame` for each finger anyway. This can cause problems for userspace separate from the issue currently taking place in the kernel. Only once all of the individual finger collections have been processed do we finally get to the enclosing collection which contains the contact count. The value ends up being used for the *next* report, however. This delayed use of the contact count can cause the driver to loose track of the actual touch state and believe that there are contacts down when there aren't. This leaves touch arbitration enabled and prevents the pen from working. It can also cause userspace to incorrectly treat single- finger input as gestures. Link: linuxwacom/input-wacom#146 Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com> Reviewed-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com> Fixes: 15893fa ("HID: wacom: generic: read the number of expected touches on a per collection basis") Cc: stable@vger.kernel.org # 5.3+ Signed-off-by: Jiri Kosina <jkosina@suse.cz>
jigpu
added a commit
that referenced
this issue
Apr 30, 2020
… per collection basis" This reverts commit 15893fa40109f5e7c67eeb8da62267d0fdf0be9d. The referenced commit broke pen and touch input for a variety of devices such as the Cintiq Pro 32. Affected devices may appear to work normally for a short amount of time, but eventually loose track of actual touch state and can leave touch arbitration enabled which prevents the pen from working. The commit is not itself required for any currently-available Bluetooth device, and so we revert it to correct the behavior of broken devices. This breakage occurs due to a mismatch between the order of collections and the order of usages on some devices. This commit tries to read the contact count before processing events, but will fail if the contact count does not occur prior to the first logical finger collection. This is the case for devices like the Cintiq Pro 32 which place the contact count at the very end of the report. Without the contact count set, touches will only be partially processed. The `wacom_wac_finger_slot` function will not open any slots since the number of contacts seen is greater than the expectation of 0, but we will still end up calling `input_mt_sync_frame` for each finger anyway. This can cause problems for userspace separate from the issue currently taking place in the kernel. Only once all of the individual finger collections have been processed do we finally get to the enclosing collection which contains the contact count. The value ends up being used for the *next* report, however. This delayed use of the contact count can cause the driver to loose track of the actual touch state and believe that there are contacts down when there aren't. This leaves touch arbitration enabled and prevents the pen from working. It can also cause userspace to incorrectly treat single- finger input as gestures. Link: #146 Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com> Reviewed-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com> Fixes: 15893fa40109 ("HID: wacom: generic: read the number of expected touches on a per collection basis") Cc: stable@vger.kernel.org # 5.3+ Signed-off-by: Jiri Kosina <jkosina@suse.cz> [jason.gerecke@wacom.com: Imported into input-wacom (b43f977dd281)] Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
jigpu
added a commit
that referenced
this issue
Apr 30, 2020
…uches on a per collection basis" This reverts commit 15893fa40109f5e7c67eeb8da62267d0fdf0be9d. The referenced commit broke pen and touch input for a variety of devices such as the Cintiq Pro 32. Affected devices may appear to work normally for a short amount of time, but eventually loose track of actual touch state and can leave touch arbitration enabled which prevents the pen from working. The commit is not itself required for any currently-available Bluetooth device, and so we revert it to correct the behavior of broken devices. This breakage occurs due to a mismatch between the order of collections and the order of usages on some devices. This commit tries to read the contact count before processing events, but will fail if the contact count does not occur prior to the first logical finger collection. This is the case for devices like the Cintiq Pro 32 which place the contact count at the very end of the report. Without the contact count set, touches will only be partially processed. The `wacom_wac_finger_slot` function will not open any slots since the number of contacts seen is greater than the expectation of 0, but we will still end up calling `input_mt_sync_frame` for each finger anyway. This can cause problems for userspace separate from the issue currently taking place in the kernel. Only once all of the individual finger collections have been processed do we finally get to the enclosing collection which contains the contact count. The value ends up being used for the *next* report, however. This delayed use of the contact count can cause the driver to loose track of the actual touch state and believe that there are contacts down when there aren't. This leaves touch arbitration enabled and prevents the pen from working. It can also cause userspace to incorrectly treat single- finger input as gestures. Link: #146 Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com> Reviewed-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com> Fixes: 15893fa40109 ("HID: wacom: generic: read the number of expected touches on a per collection basis") Cc: stable@vger.kernel.org # 5.3+ Signed-off-by: Jiri Kosina <jkosina@suse.cz> [jason.gerecke@wacom.com: Imported into input-wacom (b43f977dd281)] Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com> [jason.gerecke@wacom.com: Backported from input-wacom (f4a09e4)] Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
MilhouseVH
pushed a commit
to MilhouseVH/linux
that referenced
this issue
May 14, 2020
… per collection basis" commit b43f977 upstream. This reverts commit 15893fa. The referenced commit broke pen and touch input for a variety of devices such as the Cintiq Pro 32. Affected devices may appear to work normally for a short amount of time, but eventually loose track of actual touch state and can leave touch arbitration enabled which prevents the pen from working. The commit is not itself required for any currently-available Bluetooth device, and so we revert it to correct the behavior of broken devices. This breakage occurs due to a mismatch between the order of collections and the order of usages on some devices. This commit tries to read the contact count before processing events, but will fail if the contact count does not occur prior to the first logical finger collection. This is the case for devices like the Cintiq Pro 32 which place the contact count at the very end of the report. Without the contact count set, touches will only be partially processed. The `wacom_wac_finger_slot` function will not open any slots since the number of contacts seen is greater than the expectation of 0, but we will still end up calling `input_mt_sync_frame` for each finger anyway. This can cause problems for userspace separate from the issue currently taking place in the kernel. Only once all of the individual finger collections have been processed do we finally get to the enclosing collection which contains the contact count. The value ends up being used for the *next* report, however. This delayed use of the contact count can cause the driver to loose track of the actual touch state and believe that there are contacts down when there aren't. This leaves touch arbitration enabled and prevents the pen from working. It can also cause userspace to incorrectly treat single- finger input as gestures. Link: linuxwacom/input-wacom#146 Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com> Reviewed-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com> Fixes: 15893fa ("HID: wacom: generic: read the number of expected touches on a per collection basis") Cc: stable@vger.kernel.org # 5.3+ Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
woodsts
pushed a commit
to woodsts/linux-stable
that referenced
this issue
May 14, 2020
… per collection basis" commit b43f977 upstream. This reverts commit 15893fa. The referenced commit broke pen and touch input for a variety of devices such as the Cintiq Pro 32. Affected devices may appear to work normally for a short amount of time, but eventually loose track of actual touch state and can leave touch arbitration enabled which prevents the pen from working. The commit is not itself required for any currently-available Bluetooth device, and so we revert it to correct the behavior of broken devices. This breakage occurs due to a mismatch between the order of collections and the order of usages on some devices. This commit tries to read the contact count before processing events, but will fail if the contact count does not occur prior to the first logical finger collection. This is the case for devices like the Cintiq Pro 32 which place the contact count at the very end of the report. Without the contact count set, touches will only be partially processed. The `wacom_wac_finger_slot` function will not open any slots since the number of contacts seen is greater than the expectation of 0, but we will still end up calling `input_mt_sync_frame` for each finger anyway. This can cause problems for userspace separate from the issue currently taking place in the kernel. Only once all of the individual finger collections have been processed do we finally get to the enclosing collection which contains the contact count. The value ends up being used for the *next* report, however. This delayed use of the contact count can cause the driver to loose track of the actual touch state and believe that there are contacts down when there aren't. This leaves touch arbitration enabled and prevents the pen from working. It can also cause userspace to incorrectly treat single- finger input as gestures. Link: linuxwacom/input-wacom#146 Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com> Reviewed-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com> Fixes: 15893fa ("HID: wacom: generic: read the number of expected touches on a per collection basis") Cc: stable@vger.kernel.org # 5.3+ Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cmaiolino
pushed a commit
to cmaiolino/linux
that referenced
this issue
Jun 1, 2020
… per collection basis" This reverts commit 15893fa. The referenced commit broke pen and touch input for a variety of devices such as the Cintiq Pro 32. Affected devices may appear to work normally for a short amount of time, but eventually loose track of actual touch state and can leave touch arbitration enabled which prevents the pen from working. The commit is not itself required for any currently-available Bluetooth device, and so we revert it to correct the behavior of broken devices. This breakage occurs due to a mismatch between the order of collections and the order of usages on some devices. This commit tries to read the contact count before processing events, but will fail if the contact count does not occur prior to the first logical finger collection. This is the case for devices like the Cintiq Pro 32 which place the contact count at the very end of the report. Without the contact count set, touches will only be partially processed. The `wacom_wac_finger_slot` function will not open any slots since the number of contacts seen is greater than the expectation of 0, but we will still end up calling `input_mt_sync_frame` for each finger anyway. This can cause problems for userspace separate from the issue currently taking place in the kernel. Only once all of the individual finger collections have been processed do we finally get to the enclosing collection which contains the contact count. The value ends up being used for the *next* report, however. This delayed use of the contact count can cause the driver to loose track of the actual touch state and believe that there are contacts down when there aren't. This leaves touch arbitration enabled and prevents the pen from working. It can also cause userspace to incorrectly treat single- finger input as gestures. Link: linuxwacom/input-wacom#146 Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com> Reviewed-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com> Fixes: 15893fa ("HID: wacom: generic: read the number of expected touches on a per collection basis") Cc: stable@vger.kernel.org # 5.3+ Signed-off-by: Jiri Kosina <jkosina@suse.cz>
jpuhlman
pushed a commit
to MontaVista-OpenSourceTechnology/linux-mvista
that referenced
this issue
Jun 4, 2020
… per collection basis" Source: kernel.org MR: 103894 Type: Integration Disposition: Merged from git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable linux-5.4.y ChangeID: 1017955fab5b3cc18a3881719ebe56bc7c6e6b1b Description: commit b43f977 upstream. This reverts commit 15893fa. The referenced commit broke pen and touch input for a variety of devices such as the Cintiq Pro 32. Affected devices may appear to work normally for a short amount of time, but eventually loose track of actual touch state and can leave touch arbitration enabled which prevents the pen from working. The commit is not itself required for any currently-available Bluetooth device, and so we revert it to correct the behavior of broken devices. This breakage occurs due to a mismatch between the order of collections and the order of usages on some devices. This commit tries to read the contact count before processing events, but will fail if the contact count does not occur prior to the first logical finger collection. This is the case for devices like the Cintiq Pro 32 which place the contact count at the very end of the report. Without the contact count set, touches will only be partially processed. The `wacom_wac_finger_slot` function will not open any slots since the number of contacts seen is greater than the expectation of 0, but we will still end up calling `input_mt_sync_frame` for each finger anyway. This can cause problems for userspace separate from the issue currently taking place in the kernel. Only once all of the individual finger collections have been processed do we finally get to the enclosing collection which contains the contact count. The value ends up being used for the *next* report, however. This delayed use of the contact count can cause the driver to loose track of the actual touch state and believe that there are contacts down when there aren't. This leaves touch arbitration enabled and prevents the pen from working. It can also cause userspace to incorrectly treat single- finger input as gestures. Link: linuxwacom/input-wacom#146 Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com> Reviewed-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com> Fixes: 15893fa ("HID: wacom: generic: read the number of expected touches on a per collection basis") Cc: stable@vger.kernel.org # 5.3+ Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Corey Minyard <cminyard@mvista.com>
cesfahani
pushed a commit
to cesfahani/ubuntu-focal-ga401i
that referenced
this issue
Jun 24, 2020
… per collection basis" BugLink: https://bugs.launchpad.net/bugs/1878649 commit b43f977dd281945960c26b3ef67bba0fa07d39d9 upstream. This reverts commit 15893fa. The referenced commit broke pen and touch input for a variety of devices such as the Cintiq Pro 32. Affected devices may appear to work normally for a short amount of time, but eventually loose track of actual touch state and can leave touch arbitration enabled which prevents the pen from working. The commit is not itself required for any currently-available Bluetooth device, and so we revert it to correct the behavior of broken devices. This breakage occurs due to a mismatch between the order of collections and the order of usages on some devices. This commit tries to read the contact count before processing events, but will fail if the contact count does not occur prior to the first logical finger collection. This is the case for devices like the Cintiq Pro 32 which place the contact count at the very end of the report. Without the contact count set, touches will only be partially processed. The `wacom_wac_finger_slot` function will not open any slots since the number of contacts seen is greater than the expectation of 0, but we will still end up calling `input_mt_sync_frame` for each finger anyway. This can cause problems for userspace separate from the issue currently taking place in the kernel. Only once all of the individual finger collections have been processed do we finally get to the enclosing collection which contains the contact count. The value ends up being used for the *next* report, however. This delayed use of the contact count can cause the driver to loose track of the actual touch state and believe that there are contacts down when there aren't. This leaves touch arbitration enabled and prevents the pen from working. It can also cause userspace to incorrectly treat single- finger input as gestures. Link: linuxwacom/input-wacom#146 Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com> Reviewed-by: Aaron Armstrong Skomra <aaron.skomra@wacom.com> Fixes: 15893fa ("HID: wacom: generic: read the number of expected touches on a per collection basis") Cc: stable@vger.kernel.org # 5.3+ Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
|
Patch has been reverted upstream and in input-wacom. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I recently noticed an oddity on my Cintiq Pro 32 Touch. The pen display would randomly lose pen input completely when touch is enabled. The only workaround is to disable touch sensitivity using the physical button on the face of the display.
Although I can also disable touch in Linux driver, doing so would not prevent the problem from happening.
Extensive tests have been conducted, changing every possible thing on the BIOS settings, port arrangement, Linux driver settings ... to no effect.
It doesn't happen on my Cintiq Pro 24 (no touch), it doesn't happen under Windows. But it happens under Gnome (wayland), and KDE Plasma (xorg).
My distro is Manjaro 18.1.5, Linux 5.4. AMDGPU Polaris 10/11 cards, tested on C232 / C236 / Z370 / Z390 motherboards, Wacom Link Plus. The Cintiq Pro 32 Touch is a special model for China, it has only USB type-C input, Wacom Link Plus is required to use this product on a desktop PC, although it wasn't shipped with one. -_-
This bug must have been around for quite some time. The memory of horror goes way back in time, although I didn't draw so often back then to notice the pattern.
The text was updated successfully, but these errors were encountered: