|
317 | OpenPandora Main OS | Core | Bug Report | Medium | After disabling USB-host current still flows into USB d ... | Closed | |
Release 1 (Zaxxon) |
Task Description
On my Pandora, due to bad internal WiFi, I use an Edimax EW-7811Un USB WiFi adapter, which has a status-LED, flickering according to the network activity.
After disabling USB-host through the settings menu, the WiFi functionality is gone, but the device's LED is still on. So some current must still flow into the USB device.
The LED now has a permanent light, no flickering! This lack of "device intelligence" indicates that the device was indeed turned off, just current flowing directly to the LED circuit unaltered).
I can repeat the aforementioned steps many times, the behavior is the same.
As soon as I then first physically unplug and reinsert the device, the LED remains off eventually.
From then on, every further issuing of "Disable USB-host" through the settings menu turns the device LED completely off.
Smells like a kernel bug to me! As it requires one real un/re-plugging, from then on works ok. |
|
271 | Additional Applications | Application | Bug Report | High | BugTracker: File attachment does not work | Closed | |
All |
Task Description
If you want to file a new bug:
http://bugs.openpandora.org/index.php?do=newtask
The button "Attach a file (max. 2 MiB)" cannot be clicked.
I watched its HTML code.
It should trigger a function called uploadfilebox().
But many of the embedded javascript files are not loaded, as the server reports them as missing (404).
I.e.: http://bugs.openpandora.org/javascript/functions.js
Please make sure that the FireFly installation is complete, serving all files necessary. |
|
270 | OpenPandora Main OS | Core | Bug Report | Very Low | Power-slider & lid-close events: XFCE observes user set... | New | |
Release 1 (Zaxxon) |
Task Description
STATUS QUO:
If you are in XFCE and hold the power slider for 3 seconds, you thereby trigger the shutdown command.
For 3 more seconds a dialogue box gives you the chance to abort the shutdown ("Shutting down in 3…2…").
Now in MiniMenu no direct shutdown key is available. You first have to quit the running app (via PANDORA key), then call up the menu (via SELECT key), and then navigate to "Shutdown" and confirm it (by B or ENTER).
INQUIRED BEHAVIOR:
1) Thanks to the very recent MiniMenu speedups, these 4 consecutive user interaction steps can now at least be be executed a lot faster.
Nevertheless, offering a 1-button-interaction (via power slider) too, would be nice. Could you please make that available to MiniMenu?
And in general: Make this power-slide-event available to any possible GUI, so that not each GUI has to implement this by itself, but rather the OS catches this event and handles it uniformly, except if a certain GUI WANTS to establish an exception to the rule.
2) Also the "Lid-Close-Settings" seem to be ignored by MiniMenu. MiniMenu seems to have the action "Turn off screen" hardcoded to that event. Please make MiniMenu observe the user settings from "Lid-Close-Settings".
RELATED SOURCE CODE FILES (to my knowledge):
op_lid.sh
op_power.sh
op_bright_up.sh
op_bright_down.sh |
|
265 | OpenPandora Main OS | Application | Bug Report | Medium | MiniMenu: Flawed tab display of sub-categories if they ... | Unconfirmed | |
Release 1 (Zaxxon) |
Task Description
I assigned personal subcategories to some of my games.
Some of those subcategories share the same beginning string, i.e: Shooter, ShooterBallistic ShooterScoller.
MiniMenu displays those subcategories with flaws! See the ASCII screenshots below.
Note: The star symbols indicate the currently active selection.
The main category tab "Game" being active:
----------------------------------------------------------
| All | Audio | AudioVideo | Education |*Game*| Graphics |
----------------------------------------------------------
ActionGame AdventureGame ArcadeGame BlocksGame ...
Shooter ShooterBallistic ShooterScroller ...
GameA GameB GameC ...
----------------------------------------------------------
Now if I navigate into the sub-category "Shooter", everything normal:
----------------------------------------------------------
|*Shooter*|
----------------------------------------------------------
.. ShooterA ShooterB ShooterC ...
----------------------------------------------------------
But if I navigate to the sub-category "ShooterBallistic", strangely MiniMenu shows 2 tabs, "Shooter" and "ShooterBallistic", and jumps right into "Shooter".
----------------------------------------------------------
|*Shooter*| ShooterBallistic |
----------------------------------------------------------
.. ShooterA ShooterB ShooterC ...
----------------------------------------------------------
In order to reach my intended tab "ShooterBallistic" I need to navigate to it again. Annoying. There the contents are as expected:
----------------------------------------------------------
| Shooter |*ShooterBallistic*|
----------------------------------------------------------
.. ShooterBallisticA ShooterBallisticB ShooterBallisticC
----------------------------------------------------------
The flaw is the same for all other sub-categories beginning with "Shooter...". All have the flaw as shown in the example "ShooterBallistic", only that it is themselves instead of "ShooterBallistic". One more example to be perfectly clear:
----------------------------------------------------------
| Shooter |*ShooterScroller*|
----------------------------------------------------------
.. ShooterScrollerA ShooterScrollerB ShooterScrollerC
---------------------------------------------------------- |
|
263 | OpenPandora Main OS | Application | Bug Report | Critical | MiniMenu with "Auto discover pnd apps?" set to NO hangs ... | Closed | |
Release 1 (Zaxxon) |
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. |
|
262 | OpenPandora Main OS | Application | Bug Report | Medium | MiniMenu: 1) "Notes line" cannot be deleted. 2) Note li... | Unconfirmed | |
Release 1 (Zaxxon) |
Task Description
Steps to reproduce the bug(s):
1) In MiniMenu select an arbitrary app.
2) Press SPACE to bring up the contextual menu.
3) Select "Edit notes line 1".
4) Insert your string and confirm.
5) Now at a later time you may decide to remove your note line again. Therefore you select the same app again in MiniMenu, then repeat steps 2-3, but this time:
a) Erase all characters so that you get an empty string and then confirm. RESULT: Your change is simply ignored! There should be a possibility within MiniMenu to remove/reset note lines, the simplest being to simply accept an empty string as an input, that's what an average user will try if s/he does not find a dedicated "Delete note line" command.
b) As a workaround I tried something and detected yet another bug! As I could not create an empty string, I simply created a note line only containing 1 SPACE character (=the string " ") and confirmed. This got accepted.
If MiniMenu is in detailed view mode (press the A-button or TAB in order to bring it up, if it is not already there) and you slide over an app whose note line is " ", MiniMenu crashes!
Maybe the bug is connected with the writing to / the parsing from the .OVR (override) files which MiniMenu creates for the affected files, as the separating value in OVR files seems to be TAB, and SPACE is also WHITESPACE, therefore some parsers probably skip/misinterpret this, and MiniMenu then catches an unexpected situation!
WORKAROUND: If you ran into the problem, that you cannot get rid of the note lines anymore, simply start a file browser of your choice, navigate to the location of the affected .PND file and find its sister .OVR (override) file and delete it or edit it accordingly! |
|
261 | OpenPandora Main OS | Core | To Do (Reminder) | High | Overview of all current KEYBOARD INPUT related issues | Unconfirmed | |
Release 1 (Zaxxon) |
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 |
|
260 | OpenPandora Main OS | Core | Bug Report | Medium | Low Power Mode: Input (keyboard, nub) still taken. Appl... | Unconfirmed | |
Release 1 (Zaxxon) |
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. |
|
259 | OpenPandora Main OS | Core | Bug Report | High | Hold switch does NOT lock keyboard! Especially crucial ... | Closed | |
Release 1 (Zaxxon) |
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. |
|
258 | OpenPandora Main OS | Application | Bug Report | Low | MiniMenu: Pressing key multiple times only cycles focus... | Unconfirmed | |
Release 1 (Zaxxon) |
Task Description
EXAMPLE: MiniMenu with the option "Subcategories as folders" YES, and the current active tab i.e. "Game" lists:
Subgenre folders: ActionGame, AdventureGame, ArcadeGame, BlocksGame, …
App items: Abuse, Amoeboax, Arkaniod, Bloqus, …
THE BUG: Pressing "A" multiple times only cycles the focus between folders (ActionGame, AdventureGame, ArcadeGame), but never reaches the app items (Abuse, Amoeboax, Arkaniod).
BESIDES THIS BUG in the current keyboard item selection logic, I kindly inquire to implement: FS#243 |
|
256 | Additional Applications | Application | Feature Request | Medium | Closed lid apps (i.e. audio recording/playback) should ... | Unconfirmed | |
All |
Task Description
When the lid is closed the only remaining buttons on the Pandora are the L + R shoulder buttons and the power slider.
Applications operating in this mode should utilize that few available buttons!
Example for button utilization in a audio playback software:
L + R at once: Toggle Play/Pause
L hold: fast backward
R hold: fast forward
L click: jump to previous song
R click: jump to next song
L double click: jump to previous album/artist
R double click: jump to next album/artist |
|
255 | OpenPandora Main OS | Core | Bug Report | Medium | Waking Pandora with closed lid nevertheless turns scree ... | Closed | |
Release 1 (Zaxxon) |
Task Description
Steps to reproduce the undesired behavior:
1) Close the lid. The screen goes off.
2) Slide the power switch to the right. The device goes into low power mode. The screen remains off.
3) Slide the power switch to the right. The device goes into normal power mode and turns on the screen although the lid is still closed!
Desired behavior:
Ad 3) If the system catches the event "wake from low power mode" it should first wake the system, then check the "lid open/close state", and set the screen on/off state accordingly. By this you could use the Pandora as a power-efficient sleep/wake-able closed-lid-device, practical for i.e. audio applications.
I am using: Pandora OS R1.HF6.A4 |
|
254 | OpenPandora Main OS | Core | Bug Report | High | Several apps leave graphical artefact overlay (ghost) a ... | Closed | |
Release 1 (Zaxxon) |
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). |
|
253 | OpenPandora Main OS | Application | Feature Request | Medium | Switch GUI: Intelligent automatic choice | Unconfirmed | |
Release 1 (Zaxxon) |
Task Description
If only 2 GUIs are available, skip the user selection and switch right into the only other GUI. What else would the user want?! Right!
If more than 2, already set the focus in the GUI list to the next possible item. |
|
252 | OpenPandora Main OS | Core | Feature Request | Low | Power management: If power cable is plugged ignore "Shu... | New | |
Release 1 (Zaxxon) |
Task Description
If the power cable is plugged and the user chooses "Shutdown Pandora" from a menu, there should be a warning that this is without purpose, as the device will automatically restart.
The resulting user choices should be "Cancel shutdown" and "Shutdown nevertheless". |
|
251 | OpenPandora Main OS | Core | Feature Request | Low | SD Mass Storage: Possibility to host multiple volumes | Unconfirmed | |
Release 1 (Zaxxon) |
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) |
|
250 | OpenPandora Main OS | Application | Feature Request | Medium | File Browser Thunar - Trashing file crosses filesystem ... | Researching | |
Release 2 (.next) |
Task Description
Trashing a file/folder seems to MOVE it to a certain trash directory on the MAIN VOLUME, rather then the ORIGINATING VOLUME, hence this can result in a COPY RATHER THAN A MOVE operation, if the trashed file originates from a filesystem other than the main filesystem!
This is very inefficient and faulty as it is:
a) Very time consuming
b) And in case of large files this operation can even fail due to not enough free space on the main volume. |
|
249 | OpenPandora Main OS | Application | Bug Report | High | File Browser Thunar - After 2 nub double-clicks unreact ... | Closed | |
Release 1 (Zaxxon) |
Task Description
If I navigate via keyboard (KEY UP/DOWN to move in lists, ENTER level down, BACKSPACE level up) I experience no problems at all. I can go many levels up/down, change to other folders, etc. No problems.
But if I navigate with the nubs, and using the right-nub-up-direction to trigger a double click, this only works 1-2 times, and from then on, the files/folders in Thunar cannot be clicked any further. I am stuck then.
A look into dmesg reveals this:
keyboard.c Can't emulate rawcode for keycode 139
The timestamp of that specific keyboard.c error messages exactly correlates with the bug occurrence times. (uptime timestamps matched with dmesg timestamps)
I tried alternative filebrowsers such as emelFM2, and there the problem does not exist, meaning I can trigger as many double clicks I want!
I am using HotFix 5 Alpha 4 on an SD card. The bug already annoyed me on a HF5 on the NAND. |
|
248 | OpenPandora Main OS | Core | Feature Request | Medium | Support for hibernation by caching to SD card | Closed | |
Release 1 (Zaxxon) |
Task Description
It would be very desirable that the PandoraOS could hibernate, and that this action can easily be accessed/triggered with either a hotkey or as an action for the max-idle-time-event or lid-close-event.
That would be the battery friendly universal action to quickly pause/resume any arbitrary application/task.
The current standby mode is far to power consuming for breaks longer than ~ 1 hour. Improving standby mode to be more battery-friendly would of course be too highly appreciated and practical.
If hibernation is triggered, RAM content gets written to a special file or partition on a SD card. The boot-manager of course needs to recognize such a RAM-file on SD-cards. In case it finds more than 1, i.e.: multiple cards/partitions, the one with the newest timestamp gets priority.
256MB RAM with about 10-20 MB/s read/write time to SD, would result in 25-12 seconds for going into or out of hibernation, which would be acceptable for me. In practice it would mean, that if I quickly have to pause me OpenPandora operation (i.e. train stop), I just close my lid, and put the Pandora into my pocket (2-4 seconds), and I am then trusting that the rest reliable happens in my pocket (10-20 seconds). |
|
246 | OpenPandora Main OS | Application | Bug Report | Medium | Clipboard content of closed app gets tossed instead of ... | Unconfirmed | |
Release 1 (Zaxxon) |
Task Description
FLAWED BEHAVIOUR:
Copy and paste only works between 2 active applications. This is very limiting!
If you are in the single task oriented MiniMenu you have no chance at all to share the clipboard between apps!
If you are in the multi tasking oriented XFCE desktop environment you can only share between apps running in parallel! Not with apps which started after the source app has been terminated.
DESIRED BEHAVIOUR:
The clipboard content (within reasonable limits of course) should remain, regardless of the source application, so that you can paste at any later moment into any application. |
|
245 | OpenPandora Main OS | Core | Feature Request | Low | BugTracker: Submitter shall be able to edit bug after p ... | Closed | |
All |
Task Description
I accidentally posted a "feature request" as a "bug report" within the FlySpray BugTracker.
I wanted to correct my mistake.
It was not possible to edit it.
I assigned the bug to myself.
Then I could edit it.
But now I cannot un-assign it from me.
I merely wanted to suggest a feature but not take development responsibility (yet).
For original submitters, who later realize a mistake in their post, there should be a possibility to correct their mistake.
Please un-assign me from #237 #241 #243 and this one #245. Thanks. |
|
244 | OpenPandora Main OS | Application | Feature Request | Low | Include man and the manpages | Unconfirmed | |
Release 1 (Zaxxon) |
Task Description
The command line environment of the default OS does not include the command "man" and the respective manpages of the installed programs.
I personally often use manpages, as I hardly remember the syntax/arguments of all programs I use.
Having them would be very convenient!
EVALUATING NEEDED STORAGE AMOUNT
Some may argue that storage space is quite limited on the NAND.
Yes I agree. Hence the number of included programs is limited too. Hence it would not be all too many manpages.
When I press TAB into an empty Terminal prompt, I get 1406 possibilities, which is about the amount of available commands/programs if we ignore aliases, etc.
Multiply that with an average of 20 kb per manpage, and you get about 30 MB in total. With compression this could possibly be brought down to 15-20 MB.
POSSIBLE SOLUTIONS
A) Store into the NAND the manpages of core OS CLI programs only, and not all the library/system/etc documentation.
B) Include only the man command into the core OS, and compile/configure it in such a fashion, that it finds the manpages within non-NAND media (SD card, USB volume, etc).
b1) Specify that it simply looks into a certain path within the /media/*/pandora/ structure.
b2) Or offer PND packages like man-core.pnd, man-extended.pnd,... you get the idea or even man-custom.pnd (which would look into its appdata or a certain path for custom added manpages, to somehow get the b1 approach within the PND approach). |
|
243 | OpenPandora Main OS | Application | Feature Request | Medium | MiniMenu: Pressing successive character keys should com... | Unconfirmed | |
Release 1 (Zaxxon) |
Task Description
Imagine this tab content:
Nubs, Pandora Input, PNDstore.
CURRENT BEHAVIOR:
Pressing "P" and "N" is succession jumps to "Nubs" eventually, as it first jumps to the first "P" item ("Pandora Input"), then to the first "N" item, "Nubs".
DESIRED BEHAVIOR:
That it acts like in most Linux file browsers or the Mac OS X Finder.
In detail: Pressing "P" and "N" within a certain time limit should combine them to the string "PN" and jump to the first item which starts with that string, i.e. "PNDStore". If no item matches, reduce the combination string by one character, try to match again, if that doesn't match, try matching again with one character less, ... , until only one character is left, and if that one doesn't match jump to the nearest previous lexicographical character, which matches. |
|
242 | OpenPandora Main OS | Application | Feature Request | Medium | Pressing SHIFT + any key in sequence creates the modifi... | Unconfirmed | |
Release 1 (Zaxxon) |
Task Description
ISSUE ENVIRONMENT:
If you hold your Pandora in your hands, you only have your thumbs for typing, hence your typing abilities are quite limited.
It is hard to press more than 2 keys, and hard to press 2 keys on the same side, as your second thumb does not reach the opposite side all too easy (except you have a basketball player's hands).
The modifier keys Start/ALT Select/CTRL Pandora/(META, I guess?) are in the middle of the keyboard, hence the can easily pressed together with another key. But SHIFT lies at an ergonomically problematic side (left boundary). Hence hard to press with other left side keys.
SUGGESTED SOLUTION:
I suggest that Pandora OS offers an optional and configurable input help.
[1|2|3 presses | hold for duration x] SHIFT [timeout y] [modifier key 2] [timeout z] key
Produces the same result like SHIFT + modkey2 + key
Very likely modifier key 2 and timeout z are not necessary, as you can trigger the SHIFT hold (by your defined action), and then press the modifier key 2 and the other key at once, as the other modifier keys are laid at a central (ergonomically better) position. |
|
241 | OpenPandora Main OS | Application | Feature Request | Low | MiniMenu shall remember state for next start | Closed | |
Release 1 (Zaxxon) |
Task Description
With the setting "Live (not exit) on app run?" set to "NO" the currently selected tab and item shall be remembered, so that you return to the same state, in which you left MiniMenu. |
|
240 | OpenPandora Main OS | Application | Feature Request | Low | MiniMenu shall return into full screen mode (more quick... | Unconfirmed | |
Release 1 (Zaxxon) |
Task Description
If you set MiniMenu's option "Live (not exit) on app run?" to YES, and you quit an application and return to the still running MiniMenu, it runs in windowed mode, and takes about 2 seconds until it goes into full screen mode again.
This delay should at best be not noticeable at all, at most 0-1 seconds. |
|
239 | OpenPandora Main OS | Application | Feature Request | Low | MiniMenu: New option: Grid stop horizontal | Unconfirmed | |
Release 1 (Zaxxon) |
Task Description
I am suggesting the new option "Grid stop horizontal" for MiniMenu with the following possible settings and their effect.
Yes -> If the boundary is reached the focus remains there.
No -> If the boundary is reached the focus starts at the opposite side again.
Jump to next/prev line -> If the boundary is reached the focus jumps to the next/previous line and the opposite side. |
|
238 | OpenPandora Main OS | Application | Feature Request | Low | Quick key access to OK in dialogues | Unconfirmed | |
Release 1 (Zaxxon) |
Task Description
PROBLEM DESCRIPTION: In many GUI dialogues the default action button (OK, ACCEPT, YES, …) cannot be triggered with a simple key press. Pressing ENTER triggers the element which has focus (usually the first dialogue element), but not the default action, as most computer users would expect!
MY WORKAROUND MEANWHILE: Press ALT plus the underlined letter of your desired action. But that's not very convenient as the underlined letter needs to be looked upon first, as the button label can differ from situation to situation (ACCEPT, OK, YES, …) and then 2 keys need to be pressed.
SUGGESTED SOLUTION: The custom of many operating systems should be adapted on the OpenPandora as well. SPACE triggers the currently focused element (whatever that may be: list item, radio button, checkbox, etc), and ENTER triggers the default action of that dialogue.
Or even better use the Pandora specific A/B/Y/X keys cleverly in those dialogues/selections. I don't know whether there is a standard functionality assignment within this key-group, in MiniMenu "B" is start/confirm, I do not know of any other standard assignments yet. |
|
237 | OpenPandora Main OS | Core | Bug Report | Critical | /dev/mmcblkN - N sometimes points to left, sometimes to ... | Closed | |
Release 1 (Zaxxon) |
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. |
