gmane.comp.systems.archos.rockbox.devel

DevCon2013: your action needed

Frank Gevaerts — 2013-06-13T22:10:48

Hi,

I'm getting the impression that many people missed last week's email
about DevCon(*), so here's a reminder. Please decide you want to come,
and mark your availability on http://www.rockbox.org/wiki/DevCon2013

In case this isn't clear, current thinking is that Peter hosts in Ghent,
where we've had excellent DevCons in 2009 and 2011.

Frank

* http://www.rockbox.org/mail/archive/rockbox-dev-archive-2013-06/0003.shtml

Re: Roadmap for the imx233 target

Lorenzo Miori — 2013-06-12T13:17:36

Brilliant as always :)
Of course I appreciate the choice of commit so that my further workings on
NAND and stuff can directly go in gerrit, having the chance of organizing
work better...
As pamaury said, the port to Z5 is in a good stage, unfortunately nand
driver is still very WIP tough.

Lorenzo

2013/6/12 Marcin Bukat <marcin.bukat< at >gmail.com>

Re: Roadmap for the imx233 target

Marcin Bukat — 2013-06-12T13:00:07

Great work! In my opinion you should simply commit (and improve our recent
commit statistics) :-)


2013/6/12 Amaury Pouly <amaury.pouly< at >gmail.com>

Roadmap for the imx233 target

Amaury Pouly — 2013-06-12T12:06:23

Hello everybody,
I felt I should disclose some information about the imx233 target and the
roadmap that I have been pursuing in the last months. I'll try to start
from scratch and give you an overview of what I'm doing and why.

For those for don't know about it, the imx233 is a port to the Sigmatel
STMP3780 (aka Freescale i.MX233) SoC. It is used in at least three recent
devices: Creative Zen X-Fi2, Zen X-Fi3 and Sansa Fuze+. The port to the
Fuze+ is close to stable, same for the Zen X-Fi3 and the Zen X-Fi2 is
unstable but already has a solid basis.

The world seemed beautiful and all but then someone came and told us he had
a device based on the STMP3700 SoC for which we didn't have the datasheet
but some Linux code. It was obvious from the start that this chip was
extremely close to the imx233 and that a Rockbox port was possible. At this
point, we realised that some other devices were using another undocumented
chip named STMP3770 and we even realised that the older and documented
STMP3600 family was als

Re: Soft lock and screen/lcd activation

Lorenzo Miori — 2013-06-07T15:02:01

Regarding YP-R0, the lock buttons in WPS context is going to be the same
also in the FMS context.
I'm just telling you this because I'm pretty busy, and so I will for the
rest of the month, no chance to invest effort in rockbox at the moment :(

Lorenzo

2013/6/7 Thomas Martitz <kugel< at >rockbox.org>

Re: Soft lock and screen/lcd activation

Thomas Martitz — 2013-06-07T12:23:42

Am 07.06.2013 14:07, schrieb Amaury Pouly:

Ah, so you are saying they map the key only within the 
"button_context_wps" instance, and not "button_context_standard" which 
would make it available to the fms automatically? If yes I understand it 
now :)

Best regards.

Re: Soft lock and screen/lcd activation

Amaury Pouly — 2013-06-07T12:07:26

2013/6/7 Thomas Martitz <kugel< at >rockbox.org>

that keymap are context specific).

Re: Soft lock and screen/lcd activation

Thomas Martitz — 2013-06-07T12:04:12

Am 07.06.2013 13:49, schrieb Amaury Pouly:

But you said they have a WPS lock key, and you said there are no 
conflicts at all. Why can't they use the WPS lock key in the FMS?

Best regards.

Re: Soft lock and screen/lcd activation

Amaury Pouly — 2013-06-07T11:49:50

2013/6/7 Marcin Bukat <marcin.bukat< at >gmail.com>

Exactly.

Re: Soft lock and screen/lcd activation

Marcin Bukat — 2013-06-07T11:47:13

This means that if those targets want to use FM lock, keymap needs to be
updated IMO.

wodz


2013/6/7 Thomas Martitz <kugel< at >rockbox.org>

Re: Soft lock and screen/lcd activation

Thomas Martitz — 2013-06-07T11:06:32

Am 05.06.2013 11:13, schrieb Amaury Pouly:

What does that mean? There are no conflicts but the above targets have 
conflicts?

Best regards

Re: DevCon

Marcin Bukat — 2013-06-06T06:35:52

Do I assume correctly that this means DevCon in Gent?

wodz


2013/6/5 Peter D'Hoye <peter.dhoye< at >telenet.be>

Re: DevCon

Peter D'Hoye — 2013-06-05T11:54:11

 > I might be able to host this year but I need to write the Wiki page,
 > make a doodle to select a date and then ask my lab with the full name 
list
 > to know the final answer. I'll send a mail when the page is written.

Taking over since pamaury will not be able to host...

DevCon2013 wiki page has been created; I can host; Please populate the 
wiki page ASAP.


Peter

Re: Soft lock and screen/lcd activation

Amaury Pouly — 2013-06-05T09:13:55

I went over all keymaps which contain a lock and found no potential
conflicts. However the following devices have a WPS key lock which will
*NOT* apply to the radio screen because of the key mapping. If you want to
have radio screen lock, please improve the keymaps of those:
* YP-R0
* RK27XX
* Ondio
* Recorder
* Clip
* AV300
* Onda VX 777

Amaury Pouly


2013/6/5 Marcin Bukat <marcin.bukat< at >gmail.com>

Re: Soft lock and screen/lcd activation

Marcin Bukat — 2013-06-05T08:28:53

The change looks fairly obvious so just commit IMO.


2013/6/5 Amaury Pouly <amaury.pouly< at >gmail.com>

Re: Soft lock and screen/lcd activation

Amaury Pouly — 2013-06-05T07:32:24

I have implemented radio lock here: http://gerrit.rockbox.org/r/#/c/421/.
Can someone please review it ? Otherwise I will just commit it soon.

Amaury Pouly


2013/3/12 Jonathan Gordon <jdgordy< at >gmail.com>

Re: review to show only the chosen file's bookmarks

Richard Quirk — 2013-05-29T19:17:06

As per the earlier discussion on this, I've updated my patchset for
this to show just the bookmarks that apply for a given file.

http://gerrit.rockbox.org/r/#/c/428/

This adds a new option for the autoload bookmarks. I wasn't sure what
to do about all the .lang files though, if there's more to do then
just let me know there. It'd be great if somebody could find time to
review this to get it landed officially.

USB problems with the 5G iPod

Boris Gjenero — 2013-05-25T16:35:57

For a long time, I was having a Rockbox USB problem with my 5G 30GB 
iPod. If I plugged in USB while the hard drive was spinning, I would 
often get full speed mode instead of the much faster high speed mode. If 
I plugged in after the hard drive spun down, I would always get high 
speed mode.

This was puzzling because it is an obvious and significant problem on a 
popular target, yet nobody else seems to be having it.

Yesterday I finally created FS#12865 and investigated the problem. I 
tracked it down to a workaround for FS#12303 which resets and 
reinitializes the USB controller while the connection is being 
established the first time, causing it all to restart from the 
beginning. Depending on when this happens, it can lead to a full speed 
connection or a high speed connection. Others found some Video iPods 
require this workaround, but mine doesn't, and the workaround only 
causes problems.

The proper fix for this would be a better solution for FS#12303, which 
doesn't cause this problem. I cannot

Re: Handling of read-only storage: feeback wanted

2013-05-06T11:26:15

My Cowon D2 use real SD. I haven't been using them for a long time now but cannot remember what happens if I move the tab. I would be ready for end-user test, if no compiling or such things are not requested (wouldn't know how to)
 
I would prefer some rockbox files allowed for opening/writing (config, playlist, link, bookmark, etc..?)

An error message won't annoy user in many circumstances, it will remind him that the media is protected. Getting the message should mean the user mistakenly tried to open a file or mistakenly forgot to un-protect the media.

Steph

Re: Handling of read-only storage: feeback wanted

Lorenzo Miori — 2013-05-06T11:22:56

Definitely, user must know exactly what's going on BUT errors must not be
verbose otherwise usability decreases.
I suggest that when introducing such a new behaviour we should carefully
think about other possible behaviours (i.e. SD being removed for some
reason) and related implications, underlining the fact that we run on
several different targets.
Possible ideas:
- design new icons for the status bar
- design a new way of reporting problems to user
- define error codes and human readable messages for each one
- another effect can be the possibility to temporarily disable write
support for debugging or whatsoever reason
- define new events that can occur (also, storage may become dinamically
read only for many reasons, also fatal errors on filesystem)

All in all I find these non-functional features a great deal to make
Rockbox more robust ;)

Lorenzo
Il giorno 06/mag/2013 11:58, "Marcin Bukat" <marcin.bukat< at >gmail.com> ha
scritto:

Re: Handling of read-only storage: feeback wanted

Björn Stenberg — 2013-05-06T10:04:35

Gracefully handling read-only media requires at least a thorough review of the relevant file-writing code paths to ensure failure to write shows a (single) sensible message to the user and fails in a sane way.

It's probably even better to have a media flag that the code can check to completely avoid going into those code paths. If a user has the media write protected by choice, she will not want to be annoyed by error messages about it.