OpenPandora Main OS

This project it to track issues relating to the current shipping OS only as found here http://goo.gl/S5JCy. Please state what Hotfix you are running with any issue report. Please ONLY use this to record issues for the main OS and its default included applications - any other application issue reports should go into the Additional Applications project. Issue reports with 'in development OS images' or feature requests for the next MAJOR version (not Hotfix release) should be placed into the OpenPandora Development OS project and reported on the mailing list http://openpandora.org/cgi-bin/mailman/listinfo/firmware-dev. Please read this page to find out how to properly report bugs: http://pandorawiki.org/Reporting_bugs

IDCategoryTask TypeSeverity  ascSummaryStatusProgress
 54 CoreFeature RequestHigh Make it possible to enable / disable keyboard mappings  ...Closed
100%
Task Description Some stuff (UAE4ALL, SuperTux, etc.) is having problems because ABXY and DPAD are mapped to keyboard buttons. I guess this will lead to more problems in the near future with SDL apps, so it should be configurable to enable / disable the keyboard -> DPAD / ABXY mappings. Maybe this could be included into libpnd?
 195 CoreFeature RequestHigh Start re-recharge of battery sooner Closed
100%
Task Description Increase battery LVL_4 and LVL_3 threshold. After reaching 100%, in some cases the charge circuit enters "battery full" state, stops charging, and begins to discharge. This is not entirely unexpected behavior according to the spec sheet, although I don't fully understand exactly the situations in which it completes charging. Once the battery is full, the battery will begin discharging. The charge circuit automatically restarts the recharge once the voltage has gone below a certain level (crosses below the LVL_3 voltage threshold) The default LVL_3 voltage threshold is 3.902 volts which is at about 80-85% battery level as recorded by bq27500 chip. In my opinion, this is way too low. Setting the BCIMFTH2 register to 0xCB increases the voltage threshold to about 4.003 volts which is about 93%. Setting it to 0xDC may also be worthwhile, which is just over 95%. By default, if a user leaves their Pandora plugged in overnight, they may wake up to find their Pandora has stopped charging and the capacity has dropped to almost 80%, which can be quite startling to some users who will then report it as a bug. This change will ensure that it never drops below 93-95%, a much more acceptable level. Specific code changes suggested, in the /drivers/power/twl4030_bci_battery.c file, somewhere in the twl4030_bci_battery_probe function (or a function called by it), add the lines: /********************************/ #define KEY_FTH2 0x7F #define REG_BCIMFTH2 0x017 ret = twl4030_i2c_write_u8(TWL4030_MODULE_MAIN_CHARGE, KEY_FTH2, REG_BCIMFKEY); if (ret) return ret; ret = twl4030_i2c_write_u8(TWL4030_MODULE_MAIN_CHARGE, 0xDC, REG_BCIMFTH2); if (ret) return ret; /********************************/ (Move defines to the top, as appropriate)
 226 CoreFeature RequestHigh Boot from /dev/sda devices requested Closed
100%
Task Description Boot from usb hard disk not supported. This should be a rather simple fix of adding the sdx devices and adjust the boot scripts?? I was able to put this autoboot.txt on mmc 0:1 setenv bootargs debug root=/dev/sda1 rw rootdelay=2 console=ttyS0,115200n8 vram=6272K omapfb.vram=0:3000K ext2load sda 0:1 0x80300000 /boot/uImage bootm 0x80300000 This failed with amongst other things "Block device sda 0 not supported" and something about failing to load kernel So I then changed the autoboot file to this setenv bootargs debug root=/dev/sda1 rw rootdelay=2 console=ttyS0,115200n8 vram=6272K omapfb.vram=0:3000K ext2load mmc 0:3 0x80300000 /boot/uImage bootm 0x80300000 All this did was die after the kernel loaded. I believe I could much better make use of this device if I could boot from some faster storage, please advise :)
261CoreTo Do (Reminder)HighOverview of all current KEYBOARD INPUT related issuesUnconfirmed
0%
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
 55 CoreBug ReportCritical .xinitrc problems (image from Feb 22nd) Closed
100%
Task Description Loading a GUI from slim fails, as .xinitrc is broken. Seems to have been edited using a windows editor? From line 50 on, there are newline characters that shouldn't be there. Removing them makes XFCE4 loading fine.
 58 CoreBug ReportCritical Pandora has not been shipped yet. Closed
100%
Task Description Pandora has not been shipped yet.
 82 Base OSBug ReportCritical Network Manager - Wifi Can't Reconnect Closed
100%
Task Description When wifi drops out, or you have disconnected from it and wish to reconnect, you cant reconnect using network-manager. The connecting icon spins for a while, then it pops up the 'Password' Dialog. If you enter your password, the cycle begins again.
 208 CoreBug ReportCritical HOTFIX 4 and 5 Slow WIFI Closed
100%
Task Description I'm getting 5kb/s with bursts up to 10kb/s if I am lucky. I have attempted every channel on my router. Tried every encryption even no encryption. Tested with the router's wifi speed: 300Mbps 154Mbps and 45Mbps I'm running Hotfix 5 RC2. Wifi works fine with my android smartphone, and other wireless devices such as a laptop.
 237 CoreBug ReportCritical /dev/mmcblkN - N sometimes points to left, sometimes to ...Closed
100%
Task Description SPECIFICATION: According to http://pandorawiki.org/SD_compatibility_list /dev/mmcblk0 is the left SD card slot (the one being closer to the headphone check) /dev/mmcblk1 is the right SD card slot I trusted that device path specification. And it was correct MOST of the time. But sadly only most of the time, NOT ALWAYS!!! This bug is severely dangerous, as a (possibly critical) command could unexpectedly affect a device other than the one you intended it for! BUG INCIDENT: Sadly, I realized this bug at the worst possible moment! I issued the command: shred -fvz /dev/mmcblk0 but it erased the card in the RIGHT slot. I realized that because the card inserted on the left has 16GB, and the one on the right 128MB. I checked both the card positions and my entered command, to exclude my own mistake. Sadly it was not a clumsy mistake: This severe bug really exists! BUG REPRODUCIBILITY: I already slightly witnessed this bug during the last days, but thought it was just a coincidence. I.e. in GParted the larger card showed up at the wrong device path. I did a refresh and/or ejected/re-inserted the card, and the expected device path was back again, and I did not think further about this incident. Only today with this fatal shred incident, I eventually realized this behavior is a bug. Luckily I had my data backed up.
 263 ApplicationBug ReportCritical MiniMenu with "Auto discover pnd apps?" set to NO hangs ...Closed
100%
Task Description BUG DESCRIPTION: On my SD card with Pandora OS 1.6.4 I changed MiniMenu's setting "Auto discover pnd apps?" to NO, and then the program remained in an endless loop showing "Setting up menu...", crashing, "Setting up menu...", crashing, and so on. BUG REPRODUCTION: The variable filesystem.do_pnd_disco set to the value 0 definetely causes the crash, but maybe only in conjunction with some of my other settings?! Therefore see my attached config file mmpref.conf. Maybe related to  FS#79  , hard to tell, as this is a very minimal report. Definitely not related to my previously reported MiniMenu bug FS#262 WORKAROUND: 1) If your default GUI is: a) MiniMenu: Then after rebooting, MiniMenu will still be caught in an endless loop! Therefore boot up from an auxilary/temporary volume rather than your volume with the damaged MiniMenu! If your ruined system is on the NAND boot from an SD card, if the ruined system is on SD card, boot from NAND or another SD card. In doubt read: http://pandorawiki.org/Running_Linux_from_an_SD_card b) Other than MiniMenu such as XFCE: Then you are lucky. Simply start into XFCE, and continue with the next step. 2) Open ~/.mmpref.conf with a text editor and set the variable filesystem.do_pnd_disco to the value 1. 3) Reboot into your healed volume.
 108 Base OSFeature RequestCritical TUN/TAN-Driver Closed
0%
Task Description There is no TUN/TAN Driver installed. This is recommanded for some encrypted wireless lan connections, especially for eduroam, a world wide access point for the education community. Also, a tun-driver is also recommended for vpnc.
Showing tasks 301 - 311 of 311 Page 7 of 7<<First - 3 - 4 - 5 - 6 - 7

Available keyboard shortcuts

Tasklist

Task Details

Task Editing