Firmware suggestions and contributions


uhm, you can use fat32 cards out of the box, can't you?
 
uhm, you can use fat32 cards out of the box, can't you?


Yeah all my PND SD cards are formatted to fat32 without any playing around.. do you mean NTFS? that can be resolved with installing the codecpack if I'm not mistaken.
 
As said, FAT32 already works.


Last time I checked, exFAT implementation requires paying royalties to Microsoft. Frankly, I would oppose exFAT support on any GNU/Linux system simply because this is a slap in the face of anyone who supports freedom, but it would also drive up the cost of the Pandora, and I'm sure no one wants that. Just use FAT32.
 
Last edited by a moderator:
Unless someone has added it to an updated version of the OS, that isn't entirely true.


Although you can read and use a pre-formatted FAT32 card - you can not format one in the device without going through the OPKG mess to get the DOSFStools.


To me, a computer (the Pandora IS a computer, not just a card reader) needs to be able to format a card, not just read it.


As for ExFat - again, please follow the link I provided. It's F.R.E.E. No royalties. We would just need someone to compile it and include it in the release. From what I can tell it is being provided by Google.


http://code.google.com/p/exfat/


We shouldn't have to put a card in a reader on a PC and use a formatting tool there to do this - the Pandora IS a computer - one based on SD card media. It should be as flexible as possible in/on/around that media.
 
ExFAT is patented technology, you need to pay royalties for the patents.
Not right now you don't, and Microsoft has pinky swear promised that they'll never ever enforce their patents. Yeah, I've heard that one before.


There's nothing legally binding Microsoft from sticking to their promise, they can at any time decide to start charging royalties. They probably never will, but the argument goes "if you have no intention of charging royalties, adopt a legally binding license which says so and prove it" and if they don't then we shouldn't trust them. For something like the Pandora, where the functionality can "officially" be ripped out by a system update, I don't think we need to take such a hard stance against it, the only reason to stand against it is on principle.
 
Fact - high capacity cards are shipping from the manufacturers stock formatted as ExFAT.


Fact - the Pandora needs to be usable by individuals who consider the command line a foreign and frightening concept - who would not know the difference between EXT2 and HPFS. Their only grade for the device will be works/doesn't. They need to be able to stick in a card they just bought and have it simply work.


Fact - we can make it work. For right now (and in theory forever) there would be no fees to do so by using the -free- Google created ExFAT drivers which they have licensed as GNU GPL3.


So - quit getting your shorts all knotted up and let's make this work smoothly for future purchasers?


Telling someone who's very first Linux experience is a Pandora that they have to re-partition and re-format their nifty new SD card isn't exactly a warm welcome.
 
^ What license the driver have doesn't matter batshit if microsoft changes its mind. Although for now, it seems like it could be possible to add the drivers as microsoft isn't enforcing their patents.
 
That's what I mean. Other than taking a moral stand against them (which won't do anything but make people upset and confused) I can think of no reason not to include the exFat driver. If Microsoft turns around and starts charging, the firmware can be "officially" updated to remove it and free OPT from obligation. Meanwhile the module install floats around as a PND, but I didn't actually say that, capiche?
 
On a different track, is there a need for a 'battery charging' screen / charge indicator as found on many other devices?


I did some graphics: (available as an .xcf if anyone wants it)


(the blue bar would change length and colour depending on charge level, as well as displaying a percentage charge and providing a button to access a login screen - this would only be displayed when charging)


preview.png
 
Last edited by a moderator:
That's what I mean. Other than taking a moral stand against them (which won't do anything but make people upset and confused) I can think of no reason not to include the exFat driver. If Microsoft turns around and starts charging, the firmware can be "officially" updated to remove it and free OPT from obligation. Meanwhile the module install floats around as a PND, but I didn't actually say that, capiche?

It was more aimed at Grench, it seemed to me he assumed it was the driver that would be affected by royalties.
 
Last edited by a moderator:
Huh, exFAT is under that too, is it? Well, there's no stopping it under those terms, so all there is to do is hope Micro$oft doesn't change its mind, and if it does, that the backlash from the free software and open source communities will be big enough to get Microsoft to un-change its mind.
 
Last edited by a moderator:
You know, that there is a gparted pnd, that supports some filesystems... No need for commandlinestuff to format a sdcard.
 
Last edited by a moderator:
You know, that there is a gparted pnd, that supports some filesystems... No need for commandlinestuff to format a sdcard.

Non-starter solution. Picture the scenario.


Our subject is a new-to-linux user.


She gets a new Pandora. She gets a new SDXC card formatted as ExFAT.


You advise her to just use gparted.pnd.


She can't even download the PND it to install it because she has no functioning SD card in the machine.


So after doing 3 hours of research to figure out which card will work out of the box - she goes out and buys a small FAT32 SD card so that she can install gparted.pnd on it so that she can re-format her new SDXC card with something that will be cross-platform compatible like FAT32.


Gparted won't format FAT32 because Gparted is running command lines behind the scenes and there is no FAT32 formatting tool included in the Pandora - so it fails.


Next she's told that to format her new card as FAT32 she'll need to use command line OPKG to get the DOSFS tools in order to format FAT32 and then maybe be able to use the card. Oh, and BTW, you can't OPKG unless you first install your OS to your SD card that you can't format because...


That or she's told to format it as EXT2 - and it works on the Pandora - but then it can't be used in her camera or friend's computer or other device. So, she's told to format it to FAT32 if she wants interoperability - and can't because the Pandora can't format FAT32, only read/write to it.


In my humble opinion, we need to include the ability to format, read and write FAT32 AND EXfat in the OS in NAND. The Pandora needs to be able to read/write and re-format SD/SDHC/SDXC cards in the formats that they are purchased in.


It must be easy. What we have now is fun for a tech head, but is very very far from 'easy'.


With new cards coming out stock as ExFAT, new cameras default formatting as ExFAT, etc. - the Pandora is either going to be compatible or be a usability nightmare for the inexperienced.


Grench
 
And if you think that scenario is unlikely:





In my humble opinion, we need to get Fat32 (formatting) and ExFAT (read/write/format) into the NAND installed OS as soon as possible.


Then we need to get gparted to work happily with both - on the Pandora.
 
She gets a new Pandora. She gets a new SDXC card formatted as ExFAT.


You advise her to just use gparted.pnd.


She can't even download the PND it to install it because she has no functioning SD card in the machine.
No one has really argued that exFat shouldn't be included; someone said it, but they were wrong. You can drop this issue, please, you're just stirring a pot of your own troubles.

Gparted won't format FAT32 because Gparted is running command lines behind the scenes and there is no FAT32 formatting tool included in the Pandora - so it fails.
mkfs.vfat has been available for a while now.


Your argument is ill researched.
 
Mosh


(mobile shell)


Remote terminal application that allowsroaming, supports intermittent connectivity, and provides intelligent local echo and line editing of user keystrokes.


Mosh is a replacement for SSH. It's more robust and responsive, especially over Wi-Fi, cellular, and long-distance links.


Mosh is free software, available for GNU/Linux, FreeBSD, and Mac OS X.

http://mosh.mit.edu/


I build it for pandora but I have problems to set up an up to date Perl/IO::pty Perl module environment inside the firmware. On the other hand Mosh works nicely on pandora Arch Linux.


With/without powermanagement wifi, bad "3G" connection it can be a nice part inside the firmware. Controlling your irc, irssi, bitlbee with skype plugin chats on your home server in the garden or do some cross compilation in the bus.

I made a PND for mosh - I had some trouble with the perl stuff too, ended up including a full perl installation in the PND...





I hope this PND becomes obsolete soon ;) (mosh should really get included in one of the next firmware versions)
 
Great thread. Many useful suggestions here.

Firmware options I'd like to see are:

1) The custom KB/ nub/ gamebuttons config. per app possibility mentioned by mrLoon sounds like a great idea possibly bundled with a PND'ed xev.

2) An easy option to remap *any* keys, including the Fn + [other keys] combinations through a  GUI showing the keymap of the Pandora.

An ncurses interface for this would also be swell. The DOSBox subscreen to remap keys could serve as a template on how to tackle this.

3) A key-combo to access VT1 and possibly VT2 to escape to a pure terminal if X-Windows misbehaves.

4) a small metapackage on the PND-repo to include the Ångström repo would be nice.

ExFat support would be nice, but can also cause a lot of headaches apart from the legal limbo, since both ExFat and Fat32 cannot contain the Unix rights for files and directories. Many programs expect a proper Unix/ Linux filesystem in order to properly set up their environment.

I prefer Ext2 for my flash-based Linux filesystems that need to be opened from time to time on Windows/ MacOSX. Many OS'es have drop-in extensions available to support Ext2-Ext3 (minus journaling). For data files such as roms, this should not pose a problem, but the way that many emulators in particular are set up forces users to put those files in the appdata directory, which thus becomes a silly mixup of /etc and /home content.
 
One thing I'd like to see is the option to disable Trash in XFCE/Thunar.
I believe the Trash directory is on NAND and generally the files I delete are greater than the size available in the NAND. Deleting files straight from the SD card, skipping NAND, might reduxe the wear if it's an issue.
 
If you want that, Upgrade Pandora OS (from the System menu) (remember to have internet connected) and you'll have have Thunar with Trash disabled by default.

(Do read the disclaimer it says though. Upgrading is in testing and could break stuff... didnt break for me last time I did it, but still.)
 
Back
Top