Feature requests for HF6


Most of these features will not happen with HF6, as HotFixes only does small updates. Everything else is just too much work.

Stuff like the new XFCE, Kernel, etc. will come with the next BIG release of the OS, not with a Hotfix. There are already alpha images working of that.
Is fixing the bug that causes the shoulder buttons to time out when they're set as the mouse buttons a small update or do we need to wait for a large update to fix that?
 
I'd like to add switching to Pulseaudio or OSSv4 to the list, but I suspect those are more "Yars Revenge" level of update.
 
Well, AFAIK, there's no OSSv4 driver for our chip
Aye, that would present a problem.

and Pulseaudio eats memory, doesn't it?
2MB on my BeagleBoard, up to 15MB on my desktop. Personally I think it'd be worth it, just to get away from this bizarre OSS/ALSA thing the Pandora's got going on. Never had a problem with it myself. Anyone else feel free to jump in and correct me.
 
Or, at the *very* least - allow shoulder buttons to be used as left and right click instead of the right nub.


This really should one of the default options.

+1. Shoulder buttons as a default option instead of the right nub would be really nice.
 
Last edited by a moderator:
make pandora-button a pure modificator and setup a interface design document that sets standards.


my idea:


use pandora-button for global actions, interpreted by OS:


pandora + q = pandora.old/quit (if possible, change events, so old apps will automatically use this)


pandora + w = toggle wifi


pandora + b = toggle bluetooth


pandora + up = next desktop (xfce)


pandora + down = last desktop (xfce)


pandora + right = next window (xfce)


pandora + left = last window (xfce)


pandora + m = toggle mute


pandora + g = global menu (xfce)


pandora + space = emulator/game-menu


pandora + 1...0 = user scripts


pandora + e = executor


pandora + power = restart


use pandora-button to provide minimal in-game/emulator/app interface, interpreted by app:


pandora + s: save/quicksave


pandora + l: load/quickload


pandora + space: in-game menu


use game-buttons in a standardized way in games AND menus.


game-button x = primary, positive action (like jump or apply in a menu)


game-button b = secondary, negative action (like shoot/back in a menu)


game-button a = tertiary action, preferred for modifiers (like turbo/run button in games, delete in menus)


game-button y = quartary action, preferred for breaking events (like entering and leavin sub-menus)


shoulder-buttons = open, preferred for less frequently used actions. modificators if possible overlap with main game-buttons
 
Last edited by a moderator:
Well, AFAIK, there's no OSSv4 driver for our chip
Aye, that would present a problem.

and Pulseaudio eats memory, doesn't it?
2MB on my BeagleBoard, up to 15MB on my desktop. Personally I think it'd be worth it, just to get away from this bizarre OSS/ALSA thing the Pandora's got going on. Never had a problem with it myself. Anyone else feel free to jump in and correct me.

I had to disable it on my BB, it caused huge audio latency, around 750ms.


There could be an option hidden somewhere but after 30 mins of searching I couldn't find it, Effed it, removed Pulse, that saved some ram and storage and cpu cycles and it works fine now.


as long as programs use ALSA's "dmix" rather than "hw" it should be fine to be able to listen to some music while playing other games.
 
make pandora-button a pure modificator and setup a interface design document that sets standards.
I like that idea.

pandora + up = next window (xfce)


pandora + down = last window (xfce)


pandora + right = increase brightness


pandora + left = decrease brightness
Say what? Surely you mean this with up/down for brightness increase/decrease and left/right for previous/next windows. At least in my head left/right maps much more naturally to previous/next than to increase/decrease and vice versa for up/down.


Regardless, we already have dedicated brightness buttons (Fn+u/Fn+i).

use game-buttons in a standardized way in games AND menus.
game-button x = standard primary, positive action (like jump or apply in a menu)


game-button b = standard secondary, negative action (like shoot/back in a menu)
Standard?


Let's take the playstation layout as an example. In Europe/US the X button is used to confirm an action and the circle to cancel whereas in Japan it is reversed. In fact, the original design of the buttons seems to have been: triangle=viewpoint (representing the players head/direction), square=menu (a piece of paper), X=cancel, O=confirm. At least according to several articles on the web.


My point being, this standard will be unintuitive for at least some people (though I'm fine with the proposed choice) and will certainly be ignored by a large portion of the developers :p
 
sorry, I'm german and for us, standard means something different, i mixed those meanings exactly at that point.


What I meant is default action. I'll change it in the article. Agreed about brightness/winndows will change that to something that makes more sense.


As you say, we can't just take the layout from another system, adopt it and everyone will feel just home. The pandora is a unique system, things will have to be a little different. Still, they can be made consistent and sensefull.


Maybe a wiki-article would be the better way to work on this?


As we are still in the hf6-thread: For the next hotfix, please add htop or some graphical task manager. top sucks on pandora.
 
Last edited by a moderator:
Or, at the *very* least - allow shoulder buttons to be used as left and right click instead of the right nub.


This really should one of the default options.

+1. Shoulder buttons as a default option instead of the right nub would be really nice.
Please make it configurable (maybe also as an option during first boot, if you reflash, as well?), but please do not change the default from the right nub.


The reason I say this is that I'm guessing that changing the default would break a lot of pre-existing software (some of which might not get an update), which I'm guessing would be expecting to see the shoulder buttons as keys and not as mouse buttons.
 
Last edited by a moderator:
I'd like to see the alarm interrupt enabled so wake up on alarm works,


I managed to make my own kernel with some obvious but naive changes to enable the alarm interupt all the time - probably not the brightest way to do it...


I'd love to see a safe userland interface for setting the alarm (other than i2c directly...) and enabling the alarm iterrupt so it doesn't get switched off on shutdown


I've not done anything with procfs or sysfs but just enabling the alarm interrupts if needed would very easy to do.


I'm currently working on hacking a shutdown script which will interogate the gpe-calendar sqlite db for alarms and set the hardware alarm in time to wake the pandora up


I looked at Orage but it stores stuff in ics format which is a royal pita...!
 
Last edited:
I had to disable it on my BB, it caused huge audio latency, around 750ms.


There could be an option hidden somewhere but after 30 mins of searching I couldn't find it, Effed it, removed Pulse, that saved some ram and storage and cpu cycles and it works fine now.
Weird. I've been using mine with pulseaudio installed for months, but it never actually occurred to me to test it until now. Despite the fact that it is installed and running, everything still goes through OSS. No stream mixing or anything like that. So the pulseaudio daemon has been running and doing absolutely nothing. That seems very not right. I'll have to experiment some more.

as long as programs use ALSA's "dmix" rather than "hw" it should be fine to be able to listen to some music while playing other games.
Sure, as long as they do. A lot don't, others use OSS which results in the same thing, many of which are simple ports. We can't expect people to delve in and rewrite things that mostly work, as nice as it would be. On my desktop, before pulseaudio came along and I just had ALSA, things that used OSS were just wrapped into ALSA thinking they were using OSS, and it worked. Why isn't the Pandora's ALSA driver doing the same thing?
 
Pandora's ALSA setup is TOTALLY unique to itself (never seen or needed such a setup anywhere else in my Linux world)... I agree with at least having the option of using pulseaudio. Adding it as the standard may be stretching it, cause I hear the majority of people have bad experiences with it... I don't, personally... never have... but others seem to.


So it seems fair as more of an option than a default. I particularly am in favor of its addition simply for bluetooth audio. It has given me the easiest way to hook up a bluetooth headset BY FAR than ANY other Linux method in HISTORY! Pair the headset, open the program, open pavucontrol, pick bluetooth headset (by name) as the audio in or audio out for the program, done!


Easier than Windows, actually! About even with Mac... only paired my headset with a Mac once in my life, and I don't really remember what all I did, but I remember it being painless. That is about the ONLY request I have for HF6... I want my bluetooth headset to connect and work with audio programs (and Linphone, so I can ditch any need/desire for a cell!)...
 
*Make the Start menu more responsive


*Increase Wi-fi toggle speed (I understand that improvements can be made in that area)


*Stop Thunar from crashing whenever you incorrectly double-click


*Improve the reliability and speed of the Kill Menu


*Get rid of Arora and Midori in favor of Lightweight2 and the new Midori
 
Last edited by a moderator:
Well, AFAIK, there's no OSSv4 driver for our chip
Aye, that would present a problem.

and Pulseaudio eats memory, doesn't it?
2MB on my BeagleBoard, up to 15MB on my desktop. Personally I think it'd be worth it, just to get away from this bizarre OSS/ALSA thing the Pandora's got going on. Never had a problem with it myself. Anyone else feel free to jump in and correct me.

If I may, I'd like to vote against adding PulseAudio - on my desktop, I've had nothing but problems with it (most notably, interfering with sound in Allegro games and VLC), and it seems like it would add (unneeded) CPU load.
 
If I may, I'd like to vote against adding PulseAudio - on my desktop, I've had nothing but problems with it (most notably, interfering with sound in Allegro games and VLC), and it seems like it would add (unneeded) CPU load.
Yeah, this is an outdated opinion from me, back when I thought my BeagleBoard was using PulseAudio. I have since discovered that, while it does have PA, and is running the daemon, it doesn't actually do anything. My "not much CPU or RAM usage" was based on false information. Pulse is probably not the panacea it should be on the OMAP.
 
vminko said:
Suspend to RAM


DSP support
YES! I'd imagine once DSP is available, people will start using it. It's like upgrading to a much bigger hard drive, you think "I'll never fill all that space" but a couple months later, you're burning DVD's again to make some room.

Esn said:
I would like a single place to map/remap ALL Pandora inputs (including nubs, keyboard, should buttons, face buttons). This would all by itself solve a lot of issues with hastily-ported programs in which keys are mapped to awkward places. If you come across one, just switch your buttons mappings.
YES!

Eridger said:
a new kernel.
YES! Though I realize this one will need to wait on the OS update as EvilDragon stated.

pisiiki said:
a fix for read/write errors with "problematic" SD cards.
If possible, YES! Even if it lowers speeds, I'd rather have files that aren't corrupted. I've installed Angstrom/Debian/Gentoo to SD soooo many times just to suddenly one day have something corrupted and it becomes unbootable. Not fun, I worked hard on those!

Alerino said:
a friendly GUI on dealing with external usb controllers (2+ player mode)
YES please! Extra points to include a way to painlessly set up PS3 controllers via Bluetooth!!


Also, my own request, though this is probably more of a program request, but adding a Music/mp3 mode to the startup/shutdown menu that disables EVERYTHING but what is needed for mp3 playback, remapping skip keys to shoulder buttons, and shutting off everything else to play music in lowest-power-consumption-possible mode. Think of the attention that could get as a unique feature if you can advertise something like 50-100 hours of mp3 playback! Not to mention, there are SO many days that I don't have time to actually do anything on my Pandora except listen to music on my headphones while I work, it would be a godsend if doing so would use far less battery life.


Anyway, those are my +1's, good luck!


- trix
 
Back
Top