|
223 | Core | Bug Report | High | op_power.sh kills gles context | Unconfirmed | |
Task Description
opengles and op_power.sh don't like each other very much.
whenever returning from low power to full power mode again, opengles rendering is just dead.
the reason for this issue are following 2 lines within op_power.sh
18 echo 0 > /sys/devices/platform/omapfb/graphics/fb0/blank
...
66 echo 1 > /sys/devices/platform/omapfb/graphics/fb0/blank
if these lines are removed/commented, the gles rendering just resumes fine. |
|
226 | Core | Feature Request | High | Boot from /dev/sda devices requested | Closed | |
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 :) |
|
229 | Core | Bug Report | High | Enable wake on alarm interrupts | Unconfirmed | |
Task Description
Found I'd kept some notes about making the Pandora's wake on alarm function work...
drivers/rtc/rtc-twl4030.c
twl4030_rtc_remove (for when the driver is removed) and twl4030_rtc_
shutdown (for when the system is shutdown) functions need to change. Or at least the shut down does.
oh YUK who's been using goto....
changes in drivers/rtc/rtc-twl4030.c
twl4030_rtc_remove
commented out //mask_rtc_irq_bit(BIT_RTC_INTERRUPTS_REG_IT_ALARM_M);
twl4030_rtc_shutdown
replaced
// mask_rtc_irq_bit(BIT_RTC_INTERRUPTS_REG_IT_TIMER_M |
// BIT_RTC_INTERRUPTS_REG_IT_ALARM_M);
with
mask_rtc_irq_bit(BIT_RTC_INTERRUPTS_REG_IT_TIMER_M);
twl4030_rtc_suspend
replaced
// mask_rtc_irq_bit(BIT_RTC_INTERRUPTS_REG_IT_TIMER_M |
// BIT_RTC_INTERRUPTS_REG_IT_ALARM_M);
with
mask_rtc_irq_bit(BIT_RTC_INTERRUPTS_REG_IT_TIMER_M);
twl4030_rtc_init
added (before return!)
twl4030_rtc_alarm_irq_set_state(true);
Should probably check reg 0x2B with mask 0x08 to see if alarm should be left enabled or not ?
but only in twl4030_rtc_shutdown and ?remove? NOT in twl4030_rtc_init
should remove ever happen ???
I'm guessing it's best to not enable the alarm irq's all the time??? |
|
254 | Core | Bug Report | High | Several apps leave graphical artefact overlay (ghost) a ... | Closed | |
Task Description
After quitting some apps, their last graphical output remains on the screen, which covers a large area of the Pandora, and therefore makes it quite unusable, so that only a full restart resolves this issue.
As this happens in many apps (Mednafen-GB, Dark Light Battles, etc) this must be a problem within a shared library (driver, graphics lib, window manager framework, or similar). |
|
259 | Core | Bug Report | High | Hold switch does NOT lock keyboard! Especially crucial ... | Closed | |
Task Description
Apps, which operate with the Pandora in closed lid mode, such as audio players, server processes, etc, in a button-press-probably environment (as i.e. your pocket) still CAN receive the shoulder button L + R key presses, and if they have a meaning in these programs, they could trigger undesired actions.
And also in the current implementation of the Low Power Mode (See: FS#260) key presses may still be received.
Therefore I strongly propose to implement the HOLD switch to en/dis-able a keyboard lock.
IN DETAIL: This shall be global, meaning that the input processing software (however this is implemented on the Pandora: kernel, driver, … ) keeps the lock state (on/off), and if the keyboard state is off,
a) discards all input, or
b) if it makes sense for some reason/applications (any ideas?) just writes them into a queue/buffer, which gets (partially) executed or made accessible to certain software after the keyboard gets unlocked again.
FYI: I have tested the hold switch with the Pandora Input-Tester, and it is recognized. So my report is definitely a software (and not an hardware) issue. |
|
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 |
|
267 | Core | Bug Report | High | HF6-Updater.pnd loses pnd_run.sh | Closed | |
Task Description
Several users have reported that running HF6-Updater.pnd leads to a missing /usr/pandora/scripts/pnd_run.sh
Possibly the file is locked by the Updater itself when installing pandora-libpnd_1.0-r56.5_armv7a.ipk
Forum thread:
http://boards.openpandora.org/index.php?/topic/5652-hotfix-6-final-released/page__view__findpost__p__99313 |
|
55 | Core | Bug Report | Critical | .xinitrc problems (image from Feb 22nd) | Closed | |
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 | Core | Bug Report | Critical | Pandora has not been shipped yet. | Closed | |
Task Description
Pandora has not been shipped yet. |
|
208 | Core | Bug Report | Critical | HOTFIX 4 and 5 Slow WIFI | Closed | |
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 | Core | Bug Report | Critical | /dev/mmcblkN - N sometimes points to left, sometimes to ... | Closed | |
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. |
