|
236 | Core | Bug Report | Low | Cannot unmount SD-Card | Unconfirmed | |
Task Description
SD-Card in Pandora can only be unmounted by guest (uid=1000) but not by jgeiss (uid=1001).
Steps To Reproduce:
Insert SD-Card (or boot with SD-Card inserted),
Login as jgeiss (uid=1001),
Try to unmount SD-Card via XFCE-Popup-Menu (right mouse click on SD-Card-Icon and select unmount). |
|
251 | Core | Feature Request | Low | SD Mass Storage: Possibility to host multiple volumes | Unconfirmed | |
Task Description
a) Host multiple volumes at once.
b) Select one for hosting first, later host additional ones. (I guess this scenario is more complicated) |
|
257 | Core | Bug Report | Medium | TV Out script breaks XV/SDL Video playback | Unconfirmed | |
Task Description
This seems to be the case with Hot-fix 5 and 6 alpha 4.
I've been able to repeat this bug by re-flashing..
On a fresh re-flash.. installed community codec pack.. Videos will play fine on Panplayer, VLC and Gnome-Mplayer with default settings, which I believe is XV or SDL out in the case of VLC.
Run the TV-out script it will cause a blank black screen during playback.. Disabling TV-out, switching modes, rebooting.. battery out, nothing seems to allows it to work with XV/SDL out again.. I know If I switch to X11 it will make it "work" again, but I notice a bit of lag during playback using X11 compared to XV/SDL out. |
|
260 | Core | Bug Report | Medium | Low Power Mode: Input (keyboard, nub) still taken. Appl... | Unconfirmed | |
Task Description
This is the related documentation:
http://pandorawiki.org/Power_modes#Low_Power
(Please update accordingly as part of the issue resolution)
FROM MY USER EXPERIENCE:
If you put the Pandora into Low Power Mode, then press some keys, and then wake the Pandora back into Normal Mode, your input (both keys and nubs, haven't tried with USB input yet) seem to have triggered something while the device was in Low Power Mode!
What does really happen in Low Power Mode concerning execution and input?
a) Input is received AND triggers as application execution continues
or
b) Kernel/driver queues the input signals into a buffer, and executes them on wake?
If supposition a) or b) is true, then this would be one more reason to properly implement: FS#259
OBSERVANCE EXAMPLE 1:
1) Start MiniMenu. Mentally note down your active tab.
2) Put Pandora to Low Power Mode.
3) Press shoulder button R once.
4) Wake Pandora to Normal Mode. You are now one tab to the right of where you left. Input must have been caught in Low Power Mode, but wether execution of it happened while Low Power Mode or later after wake in Normal power Mode is unclear.
OBSERVANCE EXAMPLE 2:
1) Start gedit (a text editor). Insert the digit "1".
2) Put Pandora to Low Power Mode.
3) Press: CTRL-N 2 CTRL-N 3 CTRL-N 4. (Without the spaces)
4) Wake Pandora to Normal Mode.
5) For a fraction of a second you see the tabs building up. Either the input was really received AND executed while Low Power Mode and what you see is just a delayed window manager refreshment, or the input was queued in Low Power Mode, and only executed on wake. |
|
261 | Core | To Do (Reminder) | High | Overview of all current KEYBOARD INPUT related issues | Unconfirmed | |
Task Description
Built-in keyboard input is a central thing on the Pandora, as it concerns almost all user interfaced apps!
I realized that I myself and also others submitted quite many reports concerning this issue.
Hence this meta issue is intended as an overview/accumulation/aid for those devs who are willing to overwork the whole issue.
If you realize new related issues, feel free to add them here.
If this my effort is contradicting the OpenPandora workflow, then pardon me, and instruct me, how else to handle issues of that kind. Thanks!
Keyboard low level: Driver, keyboard layout, post processing (hotkeys, input support, etc)
FS#138 FS#227 FS#242 FS#259
Keyboard mid level: Application interfacing
FS#102 FS#123 FS#238
Keyboard application internal level
FS#157 (dupe: FS#249 ) FS#243 FS#256 |
|
269 | Core | Bug Report | Low | Thunar Slow Exit | Unconfirmed | |
Task Description
Thunar takes a long time going back to minimenu on exit. You don't notice this when in XFCE but then you are always in the GUI not returning to it.
This started in Hotfix 6 Alpha4 I believe |
|
288 | Core | Feature Request | Low | add functionality to inputrc | Unconfirmed | |
Task Description
Since the default inputrc doesn't contain any functionality (simple cli movements like ctrl-left or crtrl-right to skip words don't work) this diff may be useful to add to the cli-experience. I've also been trying to get the delete-key to work, but this is apparently already a known issue (see FS#227). I can remove this from the diff if you want. (I couldn't attach a file to the task somehow)
31,32c31,33
< # "\e[3~": delete-char
< # "\e[2~": quoted-insert
---
> #"\e[3~": delete-char
> "\e[^?": delete-char
> "\e[2~": quoted-insert
44,47c45,50
< # "\e[5C": forward-word
< # "\e[5D": backward-word
< # "\e\e[C": forward-word
< # "\e\e[D": backward-word
---
> "\e[1;5C": forward-word
> "\e[1;5D": backward-word
> "\e[5C": forward-word
> "\e[5D": backward-word
> "\e\e[C": forward-word
> "\e\e[D": backward-word |
|
290 | Core | Bug Report | Medium | gnome-mount not available | Unconfirmed | |
Task Description
In GTK applications, such as Truecrypt, NoteCase Pro or Mousepad, the file open / file save dialogs have shortcuts to mounted file systems on the left side.
If clicking such a shortcut entry, the corresponding file system's contents are shown in the right dialog pane.
This works for file systems, which were available at boot time.
For file systems mounted after booting, e.g. by inserting an SD card or connecting a USB drive, when clicking such an entry, an error message appears saying
"Could not mount [volumen name]
Failed to execute child process 'gnome-mount' (No such file or directory)"
This is healed by
sudo opkg install gnome-mount
(which instals gnome-mount, nautilus, gvfsd-ftp, gvfs (upgrade), and a lot of libs (upgrades)..
This has been seen in SuperZaxxon release 1.5, not in Beta3 (but Beta3 is the only choice in Flyspray's dropdown currently).
I reported that error for HF6 I think, and it seemed to be fixed in SuperZaxxon Beta5. A regression? |
|
292 | Core | Bug Report | Low | Can't seek in ogg files using pygame / SDL | Unconfirmed | |
Task Description
Using pygame I try to play a music file starting from some position in the middle::
import pygame
pygame.init()
pygame.mixer.init()
pygame.mixer.music.load('some_file.ogg')
pygame.mixer.music.play(0,60)
This should start playing the file from the firs minute, instead on the pandora the file plays from the start.
I've tried the same code in a debian (sid) chroot (from extend utils) and it works correctly, as it does on my pc (debian wheezy).
I suspect that the issue may be present also in .next (I've done a very quick test on a friend's pandora).
Some relevant version numbers:
* libogg.so.0.6.0 (on debian libogg.so.0.8.0)
* libSDL_mixer-1.2.so.0.10.1 (on debian libSDL_mixer-1.2.so.0.12.0) |
|
297 | Core | Bug Report | Low | pandora button and taskbar autohide | Unconfirmed | |
Task Description
When the taskbar is set to autohide, the Pandora button does not bring up the menu anymore. |
|
300 | Core | Bug Report | Low | SuperZaxxon interprets on-disk FAT32 filenames differen... | Unconfirmed | |
Task Description
With SuperZaxxon Final, I've noticed that stuff running on the Pandora like Thunar and bash are seeing a different interpretation of filenames on disk than when I remove the SD card and insert it into my desktop PC.
Specifically, the following two mismatches appear to be present when using a FAT32-formatted SD card:
First, the Pandora's VFAT support seems to be be operating with different case-handling settings than desktop Linux distros.
Filenames set in all uppercase are forced to all-lowercase on the Pandora (whether they're set on the desktop or the Pandora) but inserting the card into a PC reveals that the. All-lowercase filenames set by software on the Pandora risk appearing in all uppercase when the card is inserted into a PC. (I think the grsync PND is what created the files in question)
Among other things, this forces me to use EITHER the PND-based copy of grsync over the network OR a desktop-based copy of rsync with an SD card reader but not both because the kernel will preserve case differences like ALBION.BAT vs. albion.bat but rsync think they are separate files. (resulting in Flash-killing, time-wasting deletion and re-creation)
It also makes for irritating entries like "zzt" in DOSBox or "ddr" in PyDance where I can't capitalize the filename properly without employing Department of Redundancy Department with "DDR Songs" or "ZZT.The.Game" as an excuse for mixed case.
Second, SuperZaxxon Final seems to be using a different (though still Unicode-capable) filename encoding than all the desktop distros I've tried.
Filenames are preserved properly and all-ASCII filenames are displayed properly in all cases, but any non-ASCII characters appear as gibberish on whichever system was not used to set them.
I've confirmed this problem with these two filenames:
- 03 - The Foggy Dew with Sinéad O'Connor.flac
- Lucky Star - Native Misao (Touhou - Native Faith) ???????????????????×??????.mp4
As a Canadian user, my desktops use the "en_CA.utf8" locale and the only other distros I've found which have this problem are Slax and the 1.0 release of its successor, Porteus, both of which use ISO-8859-1 (latin1) for filenames. |
|
301 | Core | Bug Report | Medium | Missing X keybinding for colon symbol | Unconfirmed | |
Task Description
As verified with xev, an attached bluetooth keyboard can not generate colon (shift semicolon). xmodmap shows that (unlike a standard Linux system) shift-semicolon is mapped to NoSymbol. While it's find that there's a special symbol to get semicolon on the built-in keyboard, the other binding really should be there in support of attached keyboards. |
|
307 | Core | Feature Request | Medium | Change how Automatic Shutdown works | Unconfirmed | |
Task Description
When thee Pandora is shutting down because its almost out of power, it should check to make sure that the nub inputs are set to the default mode (which is mouse movement for the left nub and mouse buttons for the right nub). If not, it should change them to be like that. |
|
308 | Core | Bug Report | Low | Wireless Network being dropped asks for password | Unconfirmed | |
Task Description
When a Wireless Network that is dropped because its signal strength isn't that good gets reconnected to, I am being asked to re-input the password for that network. It would be nice if it just used the password I gave to it when it was able to connect without popping up that dialog box. |
|
315 | Core | Bug Report | Medium | Pairing bluetooth SPP devices doesn't work with XFCE | Unconfirmed | |
Task Description
Hi, sadly the XFCE bluetooth manager seems to have problems with pairing simple SPP devices (an BT GPS mouse here).
1. Enable BT
2. BT Manager -> Add new device
3. Confirm Dialog and wait for scanning
4. Pick device
5. Select PIN options -> "0000" (here for me)
In next step the dialog still asks you to enter a random PIN at your BT device (which is impossible here).
Thus it seems, that the XFCE dialog makes troubles, I tried it with 2 different GPS. Pairing the GPS manually works fine:
sudo rfcomm connect rfcomm0 00:18:E4:26:5F:14 |
|
320 | Core | Bug Report | Low | Bluetooth connection lost after wake-up from sleep mode | Unconfirmed | |
Task Description
When an internet connection was established through a mobile phone (Android, tethering) via bluetooth, the internet connection will not be re-established when the Pandora was sent to sleep and woken up again. The Pandora seems to be connected to the mobile phone, but no internet connection can be established, not even when manually trying to connect. The only way out is to disable bluetooth and enable it again.
I had similar problems with WiFi, before notaz tweaked the system (http://boards.openpandora.org/index.php/topic/11416-wifi-mysteries-resolved-once-and-for-all-—-power-saving-is-clearly-the-culprit/?p=249036). |
|
324 | Core | Bug Report | Low | Sticky keys setting for shift key disabling itself afte... | Unconfirmed | |
Task Description
The sticky keys option is disabling itself for the shift key. It continues to work with the left shoulder button though.
Unfortunately I have no idea what triggers the sticky option to be disabled. Sometimes it happens after 1-2 minutes, sometimes it takes longer.
I would also like to point out that using the shoulder button instead of the shift button it _not_ an option! This issue has been reported in the forums, but apperantly was never fixed. |
|
325 | Core | Bug Report | Low | Impossible to not set password at first boot | Unconfirmed | |
Task Description
The Wiki states that the Pandora can be used without setting a user password on first boot. But when the password and password confirmation field are left empty, an error pops up saying that there is a password missmatch.
(Please don't fix this bug by just changing the statement in the Wiki ;-) |
|
326 | Core | Bug Report | Low | XFCE menu not expandingl with stylys and scrolling brok... | Unconfirmed | |
Task Description
The XFCE menu does not always show submenues like "Emulators" when being clicked on with the stylus. It only works if the click lasts long or after all menues have been clicked at once with a long click.
Also, tipping on a scroll arrof of menues that are higher than the screen causes the click to be registered as a "click and hold". This leads to the menu being scrolled all the way to the end. |
|
327 | Core | Feature Request | Low | Context menu for the XFCE menu | Unconfirmed | |
Task Description
Right now. the XFCE menu handles right clicks like left clicks. It would be more logical to either not do anything on a right click, or open a context menu that e.g. lets the user generate a link to an application on the desktop. |
|
329 | Core | Bug Report | Low | Screen turns on when LCD closed | Unconfirmed | |
Task Description
Issue: The screen accidentally turns on even when the lid is closed.
How to reproduce: "Screen blanking" must be enabled! Close the lid, wait more than 10 minutes, tap either shoulder button. This behaviour happens whether on charge or battery, at the desktop or running an application, provided that the "screen blanking" option is enabled.
Desired outcome: When the Pandora comes out of "screen blanking", it should restore the brightness to the same value that it was before blanking. |
|
330 | Core | Bug Report | Low | NetworkManager crashes after suspend to RAM | Unconfirmed | |
Task Description
Suspend to RAM uses less power than the low power mode, but the NetworkManager crashes often after the Pandora woke up from suspend to RAM.
This could be fixed with an update of NetworkManager. |
|
331 | Core | Bug Report | Medium | Hold switch key continuously sends X11 KeyPress events ... | Unconfirmed | |
Task Description
When put into Hold mode, X11 handles the power switch as if it's being pressed, and it generates lots of keypress events, passing them to the foreground application. Since /dev/input/eventX does not seem to continuously trigger, I'm guessing it's due to key repeat.
To reproduce:
- Install xev and open it in the terminal
- Put the power key in HOLD mode
- Notice the "time" value changing rapidly
In addition to causing more work to X, it also floods the active application with key presses, resulting in increased CPU usage. In my test, switching to HOLD while Firefox is in the foreground causes it to use 6% CPU and X an additional 2.5%.
In addition, the key-press events continue even after the switch is taken off HOLD until another key is pressed.
A possible solution to this is to blacklist the power-button event device, to prevent evdev from listening to it (the key is handled by pndevmapperd). |
|
336 | Core | Bug Report | Medium | Touch screen sensitivity too low | Unconfirmed | |
Task Description
The touch screen requires to be used with the stylus or another sharp object. Even if I need to click a desktop icon, and could as well use my finger, the touch screen won't react to my finger at all (even if pressed quite hard). |