[Touch-packages] [Bug 1759300] Re: Gnome Shell: Touchpad right click (bottom right) area does not work
Would it be possible to make 'area' mode the default if the touchpad doesn't support multi-finger input? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gsettings-desktop-schemas in Ubuntu. https://bugs.launchpad.net/bugs/1759300 Title: Gnome Shell: Touchpad right click (bottom right) area does not work Status in gsettings-desktop-schemas package in Ubuntu: Invalid Bug description: The right (second) touchpad click does not work. It ceased to work about three months ago. ubuntu 18,04 aser ex2519 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gsettings-desktop-schemas/+bug/1759300/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1766480] [NEW] Touchpad scroll and middle/right click not working as expected
Public bug reported: This could probably fixed through configuration, but it should work automatically. Testing Ubuntu 18.04 beta, the touchpad has no special regions for scrolling or anything. By default in Xorg-based Ubuntu, top right corner of touchpad is middle- click (mouse button 2), bottom right is right-click (mouse button 3), and right side is vertical scrolling. For a while the bottom edge defaulted to horizontal scrolling, but that changed in 17.10 or something. I'm aware that new touchpad interaction methods have developed, like dragging with two fingers anywhere on the touchpad to scroll or something. But people may not know this, or their touchpad might not support multitouch. (The Xorg-based settings for touchpad remain when switching back to Xorg like with the Metacity Flashback login option.) ** Affects: wayland (Ubuntu) Importance: Undecided Status: New ** Description changed: This could probably fixed through configuration, but it should work automatically. Testing Ubuntu 18.04 beta, the touchpad has no special regions for scrolling or anything. By default in Xorg-based Ubuntu, top right corner of touchpad is middle- click (mouse button 2), bottom right is right-click (mouse button 3), and right side is vertical scrolling. For a while the bottom edge defaulted to horizontal scrolling, but that changed in 17.10 or something. I'm aware that new touchpad interaction methods have developed, like dragging with two fingers anywhere on the touchpad to scroll or something. But people may not know this, or their touchpad might not support multitouch. + + (The Xorg-based settings for touchpad remain when switching back to Xorg + like with the Metacity Flashback login option.) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wayland in Ubuntu. https://bugs.launchpad.net/bugs/1766480 Title: Touchpad scroll and middle/right click not working as expected Status in wayland package in Ubuntu: New Bug description: This could probably fixed through configuration, but it should work automatically. Testing Ubuntu 18.04 beta, the touchpad has no special regions for scrolling or anything. By default in Xorg-based Ubuntu, top right corner of touchpad is middle-click (mouse button 2), bottom right is right-click (mouse button 3), and right side is vertical scrolling. For a while the bottom edge defaulted to horizontal scrolling, but that changed in 17.10 or something. I'm aware that new touchpad interaction methods have developed, like dragging with two fingers anywhere on the touchpad to scroll or something. But people may not know this, or their touchpad might not support multitouch. (The Xorg-based settings for touchpad remain when switching back to Xorg like with the Metacity Flashback login option.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wayland/+bug/1766480/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1766479] [NEW] Resizing a window's left border to the right can cause it to scoot right
Public bug reported: Tested with 18.04 beta. Created a small window, ffmpeg or ffplay showing a 2x2 pixel video. When trying to move it, instead selected left border. Dragging right caused the window to scoot away faster than the pointer was moving, vanishing in less than a second. ** Affects: wayland (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wayland in Ubuntu. https://bugs.launchpad.net/bugs/1766479 Title: Resizing a window's left border to the right can cause it to scoot right Status in wayland package in Ubuntu: New Bug description: Tested with 18.04 beta. Created a small window, ffmpeg or ffplay showing a 2x2 pixel video. When trying to move it, instead selected left border. Dragging right caused the window to scoot away faster than the pointer was moving, vanishing in less than a second. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wayland/+bug/1766479/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1407644] Re: eog doesn't show WebP images
The bug for eog seems to be Bug #1318327. Should one of these bugs be marked as a duplicate and the other project added to the list of affected projects? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libwebp in Ubuntu. https://bugs.launchpad.net/bugs/1407644 Title: eog doesn't show WebP images Status in WebP Image Library: Unknown Status in libwebp package in Ubuntu: Confirmed Bug description: eog doesn't show WebP images i get this error message while trying to view WebP images Could not load image '2_webp_a.webp'. Unrecognized image file format To manage notifications about this bug go to: https://bugs.launchpad.net/libwebp/+bug/1407644/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1443846] [NEW] 'Advance by one frame' no longer works at beginning of video
Public bug reported: This might be a totem issue, not a gstreamer one; the ubuntu-bug program asked what was happening and I selected "video not playing correctly". After I upgraded from Ubuntu 12.04 to Ubuntu 14.10, with whatever gstreamer or totem changes were involved with that, 'advance by one frame' (the '.' key) didn't work as well. It will almost always not work at the very start of a video. Sometimes instead of one frame, it will advance around half a second. Other times, maybe related to seeking in the video after using it without first starting normal playback again, it will not work properly or will send you back to where you were in the video before you seeked to a different time. Occasionally, it will work at the start of a video, but very rarely if ever can you do this by pausing, seeking to the start of a video, and then pressing '.' . You used to be able to do this though. Right now, trying to seek near the start of a video, if it doesn't just send you back to wherever you were, usually skips several frames, like 6 frames or so, then starts normal behaviour of advancing 1 frame at a time. On a related note, the 'one frame back' key (the ',' key) is either broken by design or partly by accident. Pressing it usually either freezes the video, so you have to seek to a different location in order for the video to start playing normally, or it causes the video to seek to a totally separate time, and subsequently pressing '.' causes a frame to be shown which is at a completely separate time than what ',' was returning. When ',' works instead of freezing the video (possibly only before I upgraded to 14.10 several months ago), it seemed to usually seek to near the start of the video before returning frames, though the '.' key would sort of let you reset playback to where it was before. As a quick test, I just tried it on a webm/VP9 video, though I think the same thing happens with other videos: 1) Played for a few seconds, then pressed and held '.' . Result, video advances at the rate of keyboard sending '.' events. 2) Pressed and held ','. Result, video went back maybe a second, but then actually played backwards. 3) Pressed and held '.' again. Result, video played backwards instead of advancing forwards like the key should do. 4) With video paused, seeked forward by 15 sec, and pressed '.' again. Result, progress bar moved back to video start where it was before seeking, and video didn't advance as probably still trying to go backwards. 5) With video paused, seek forward by clicking. Unpause video. Result, it goes back to start and doesn't play. 6) With video on play but not playing, seeked forward again. Result, starts playing from beginning. 7) With video on play and playing, seeked to a different location. Result, video still on play but not playing. 8) Paused and then unpaused, video starts playing again. 9) Pressed and held '.' again, video slowly moves forward. 10) Pressed ',' , totem crashes. (don't remember this happening before) ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: libgstreamer1.0-0 1.4.3-1 ProcVersionSignature: Ubuntu 3.16.0-30.40-generic 3.16.7-ckt3 Uname: Linux 3.16.0-30-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.14.7-0ubuntu8.2 Architecture: amd64 CurrentDesktop: Unity Date: Tue Apr 14 02:12:17 2015 SourcePackage: gstreamer1.0 UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: gstreamer1.0 (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug utopic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gstreamer1.0 in Ubuntu. https://bugs.launchpad.net/bugs/1443846 Title: 'Advance by one frame' no longer works at beginning of video Status in gstreamer1.0 package in Ubuntu: New Bug description: This might be a totem issue, not a gstreamer one; the ubuntu-bug program asked what was happening and I selected "video not playing correctly". After I upgraded from Ubuntu 12.04 to Ubuntu 14.10, with whatever gstreamer or totem changes were involved with that, 'advance by one frame' (the '.' key) didn't work as well. It will almost always not work at the very start of a video. Sometimes instead of one frame, it will advance around half a second. Other times, maybe related to seeking in the video after using it without first starting normal playback again, it will not work properly or will send you back to where you were in the video before you seeked to a different time. Occasionally, it will work at the start of a video, but very rarely if ever can you do this by pausing, seeking to the start of a video, and then pressing '.' . You used to be able to do this though. Right now, trying to seek near the start of a video, if it doesn't just send you back to wherever you were, usually skips several frames, like 6 frames or so, then starts normal behaviour of advancing 1 frame at a t
