<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.comp.systems.archos.rockbox.devel">
    <title>gmane.comp.systems.archos.rockbox.devel</title>
    <link>http://blog.gmane.org/gmane.comp.systems.archos.rockbox.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10942"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10937"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10936"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10933"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10928"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10925"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10911"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10909"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10904"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10903"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10892"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10891"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10888"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10887"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10886"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10885"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10876"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10873"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10872"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10869"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10942">
    <title>USB problems with the 5G iPod</title>
    <link>http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10942</link>
    <description>&lt;pre&gt;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 &lt;/pre&gt;</description>
    <dc:creator>Boris Gjenero</dc:creator>
    <dc:date>2013-05-25T16:35:57</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10937">
    <title>Handling of read-only storage: feeback wanted</title>
    <link>http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10937</link>
    <description>&lt;pre&gt;Hi ,
I'm looking for some feedback on an issue which might not be one: read-only
storage. It appears that since virtually all DAP use micro-sd card we never
ran into this problem but I am porting Rockbox to the Creative ZEN and ZEN
X-Fi which feature a real SD card port and can sense the write-protected
switch of them.
The obvious solution is to completely ignore it of course but this is a bit
of shame. Another option is to simply fail all writes to the storage if it
is write protected (remember that this is completely software handled).
I am wondering if there would be any interest in doing something a bit more
clever, like making the file system code aware of read-only storage.
Indeed, failing all writes will potentially stress all write path, might
trigger bugs or obscure error messages to the user. A simple solution would
be to prevent opening opening a file for writing for example.

Any thoughts ?

Amaury Pouly
&lt;/pre&gt;</description>
    <dc:creator>Amaury Pouly</dc:creator>
    <dc:date>2013-05-06T09:22:51</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10936">
    <title>Rockbox Ondio</title>
    <link>http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10936</link>
    <description>&lt;pre&gt;Hi there,

who ist responsible for the Ondio port. Ist anyone interested but needs 
a device? I am mainly asking, because the Ondio FM port has problems 
with the radio.

Malte

&lt;/pre&gt;</description>
    <dc:creator>Malte Schmidt-Tychsen</dc:creator>
    <dc:date>2013-04-29T08:18:37</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10933">
    <title>DevCon</title>
    <link>http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10933</link>
    <description>&lt;pre&gt;Are we going to have one this year?


Marcin Bukat (wodz)
&lt;/pre&gt;</description>
    <dc:creator>Marcin Bukat</dc:creator>
    <dc:date>2013-04-26T09:14:31</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10928">
    <title>review to show only the chosen file's bookmarks</title>
    <link>http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10928</link>
    <description>&lt;pre&gt;This change is a bit larger than my last minor bookmark tweak. Again
autoload bookmarks is set to "ask". Opening a track showed all of the
bookmarks for any track in the current directory, not just bookmarks
for the track you chose to open.

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

The main change was to separate out a filtered count from the visible
count of bookmarks, and then remember to filter again when moving down
the list. This is because the bookmark list is cached, behaviour that
has not changed here.

This forum post asks for a similar feature, but adding it to the "ask"
list is easier and less controversial than adding a new menu entry
http://forums.rockbox.org/index.php/topic,42815.0.html

&lt;/pre&gt;</description>
    <dc:creator>Richard Quirk</dc:creator>
    <dc:date>2013-04-21T19:44:09</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10925">
    <title>Ladies and gentlemen, we have sound on the RCA RC3000A digital boombox</title>
    <link>http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10925</link>
    <description>&lt;pre&gt;Over the last few weeks I've been working on a port to the RCA RC3000A 
digital boombox. I now have flawless playback, including via the 
speakers. The first successfully played song was Mika - Un Soleil Mal 
Luné in FLAC format, from an SD card.

It's based on the TCC760 SoC, which has a USB boot mode allowing 
convenient development without risk of bricking or need to write code to 
storage. The mode is a bit different from later Telechips SoC supported 
by tcctool: the 4th parameter is execution starting address not SDCFG. I 
can still upload to SDRAM by first uploading a small program to set 
SDCFG and then uploading to SDRAM.

Rockbox has drivers for the LCD, tuner and RTC. The LCD only needs a 
different initialization sequence. The SoC has similarities to TCC77x 
and the codec has similarities to CS42L55, but there are important 
differences, so I'm making new drivers for them. I used Archos Ondio 
ata_mmc.c as a starting point for the SD driver because it also uses 
SPI, but it seems I should be usi&lt;/pre&gt;</description>
    <dc:creator>Boris Gjenero</dc:creator>
    <dc:date>2013-04-20T18:50:13</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10911">
    <title>540e5d1: Forget about fixedpoint.c in any HWCODEC bin.</title>
    <link>http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10911</link>
    <description>&lt;pre&gt;


Calling apps/ code from firmware? That's bad!

Why not move fixedpoint to firmware (or into the top level lib folder)?

Best regards

&lt;/pre&gt;</description>
    <dc:creator>Thomas Martitz</dc:creator>
    <dc:date>2013-04-15T21:43:45</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10909">
    <title>HD targets and multivolume</title>
    <link>http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10909</link>
    <description>&lt;pre&gt;People seem to be experimenting with 240GB drives in most HD-based
targets these days. On some of them, the OF bootloader won't do
LBA48, so the first partition needs to be smaller than 128GB, which
means you have to have two partitions for it to be fully usable.

I think we should enable HAVE_MULTIVOLUME on all HD targets with at
least 8MB RAM. The overhead is less than 3KB, which I think is
negligible on those devices.

Comments?

Frank


&lt;/pre&gt;</description>
    <dc:creator>Frank Gevaerts</dc:creator>
    <dc:date>2013-04-13T14:52:05</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10904">
    <title>review for minor bookmark ui tweak</title>
    <link>http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10904</link>
    <description>&lt;pre&gt;This minor UI change adds a way to cancel out from the bookmark list
that is shown when you have autoload bookmarks = ask.

http://gerrit.rockbox.org/416

Without this change, pressing a cancel button starts the track from
the start, which felt unexpected to me. With the change, cancelling
goes back to the file list.

&lt;/pre&gt;</description>
    <dc:creator>Richard Quirk</dc:creator>
    <dc:date>2013-04-06T07:27:12</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10903">
    <title>Debug build break recording</title>
    <link>http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10903</link>
    <description>&lt;pre&gt;Hi all,
While trying to implement recording on the Fuze+ I stumbled upon a very
nasty bug which took me quite a few hours do track, so I would like to make
you aware of it and ask for advise. To cut the long story short: if you
compile rockbox in DEBUG, any attempt to record something will result in a
crash.

If you compile rockbox in debug mode (select Debug in tools/configure), the
following will happen:

* -DDEBUG will be added to GCCOPTS in Makefile
* the codec "vtable" will get an additional field in firmware build:
(lib/rbcodec/codecs/codecs.h):
#if defined(DEBUG) || defined(SIMULATOR)
    void (*debugf)(const char *fmt, ...) ATTRIBUTE_PRINTF(1, 2);
#endif
* the rbcodec makefile will undefine DEBUG:
(lib/rbcodec/codecs/codecs.make):
 CODECFLAGS += -UDEBUG -DNDEBUG
* the codecs will be built without the additional field in codec vtable and
without DEBUG
* the encoder codecs will be broken because all the encoder specific
functions are *after* debugf in the "vtable", but the playback ones will be
fine th&lt;/pre&gt;</description>
    <dc:creator>Amaury Pouly</dc:creator>
    <dc:date>2013-04-01T14:26:15</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10892">
    <title>Soft lock and screen/lcd activation</title>
    <link>http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10892</link>
    <description>&lt;pre&gt;Hi all,
As you know, many of our targets features a "soft-lock" in the WPS which
locks all the keys except the unlock key, to prevent accidental changes.
This is a very useful feature but recent targets like the Fuze+ have shown
that it is too limited in two ways:

1) Only in WPS
This feature only exists in the WPS screen, which kind of make sense if you
listen to music but this is not the only screen where it would be useful.
One of the most asked one is the radio screen where you currently cannot
lock the keys.

2) Doesn't prevent screen activation
Another problem which is more specific to the Fuze+ is that it features a
touchpad which you can easily touch, and thus will constantly activate the
screen/lcd. This is bad for the battery life and this is also very
annoying. That's precisely why most phones on the market just won't respond
to touch events when locked and you'll need to touch a physical buttons to
activate it again. I think it would be very sensible to have such a feature
in Rockbox too.

To sum&lt;/pre&gt;</description>
    <dc:creator>Amaury Pouly</dc:creator>
    <dc:date>2013-03-11T15:42:04</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10891">
    <title>Rocbox 3.13 released!</title>
    <link>http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10891</link>
    <description>&lt;pre&gt;Hello all,

On behalf of the Rockbox developers, I'm very pleased to announce that 
Rockbox 3.13 has just been released!

Go here to download the installer (individual zips are also available):

          http://www.rockbox.org/download/

Read up on the most noticeable changes in 3.13:

          http://www.rockbox.org/wiki/ReleaseNotes313

Unfortunately the Nano 2g isn't included in this release, but Rockbox 
Utility will offer to install either 3.10 or the latest development 
build for you.

And above all, enjoy!

Alex

&lt;/pre&gt;</description>
    <dc:creator>Alex Parker</dc:creator>
    <dc:date>2013-03-08T14:37:55</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10888">
    <title>Which player to buy?</title>
    <link>http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10888</link>
    <description>&lt;pre&gt;Hello rockbox-dev.

I've been using Rockbox for a long time (first on my 4th gen iPod, then on
my iPod nano 1G and now my Sansa Clip v2) and lurking on this list for a
short time.

I have a little bit of money to spend on a new MP3 player, and I'd like to
buy one that Rockbox still has issues on so I can (1) have a new MP3 player
and (2) help test Rockbox. I'd like to get a cheap used or refurb SanDisk
player, but that's just because I'm partial to the Sansa players. If
something else small and cheap like that needs a tester more, that's cool,
too.

Any recommendations? Any Sansas need more testing? FWIW, I know how to
build Rockbox from git... I just can't really code. Just want to give back
to Rockbox by testing on a player that needs the attention.

Thanks. And thanks for Rockbox, because it's awesome.
&lt;/pre&gt;</description>
    <dc:creator>Domain Admin</dc:creator>
    <dc:date>2013-02-25T21:56:52</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10887">
    <title>Branched for 3.13</title>
    <link>http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10887</link>
    <description>&lt;pre&gt;Hi all

We have branched for 3.13.

This means master is open for new features again, but bugfixes of course
remain very welcome.

If all goes well, we'll release in a week.

You can get the new branch using "git checkout v3.13", and changes for
the stable release can be pushed to refs/for/v3.13 if you want them to
be reviewed.

Alex

&lt;/pre&gt;</description>
    <dc:creator>Alex Parker</dc:creator>
    <dc:date>2013-02-24T18:11:53</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10886">
    <title>bulgarian localizator for 3.13</title>
    <link>http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10886</link>
    <description>&lt;pre&gt;     Hi devs,
I'm sending you the updated Bulgarian localization for the upcoming release.

1. I've rearranged phrases to match the English file.
2. I've translated all untranslated strings.
3. I've corrected some wrong translated strings.
4. I've translated all voice strings, which were missing in previous 
version.

I'm sending you my bulgarian.lang file (attached). It compiles correctly 
, and seems OK in a simulator.
Please include it in the upcoming release.

I'm translating the user manual too, but it is not ready to be released 
yet. If someone would like to join - please send me an e-mail.

Best regards,
Zahari Yurukov

#             __________               __   ___.
#   Open      \______   \ ____   ____ |  | _\_ |__   _______  ___
#   Source     |       _//  _ \_/ ___\|  |/ /| __ \ /  _ \  \/  /
#   Jukebox    |    |   (  &amp;lt;_&amp;gt; )  \___|    &amp;lt; | \_\ (  &amp;lt;_&amp;gt; &amp;gt; &amp;lt;  &amp;lt;
#   Firmware   |____|_  /\____/ \___  &amp;gt;__|_ \|___  /\____/__/\_ \
#                     \/            \/     \/    \/            \/
# $&lt;/pre&gt;</description>
    <dc:creator>Zahari Yurukov</dc:creator>
    <dc:date>2013-02-20T19:21:07</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10885">
    <title>bulgarian localization for 3.13</title>
    <link>http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10885</link>
    <description>&lt;pre&gt;     Hi devs,
I'm sending you the updated Bulgarian localization for the upcoming release.

1. I've rearranged phrases to match the English file.
2. I've translated all untranslated strings.
3. I've corrected some wrong translated strings.
4. I've translated all voice strings, which were missing in previous 
version.

I'm sending you my bulgarian.lang file (attached). It compiles correctly 
, and seems OK in a simulator.
Please include it in the upcoming release.

I'm translating the user manual too, but it is not ready to be released 
yet. If someone would like to join - please send me an e-mail.

Best regards,
Zahari Yurukov

#             __________               __   ___.
#   Open      \______   \ ____   ____ |  | _\_ |__   _______  ___
#   Source     |       _//  _ \_/ ___\|  |/ /| __ \ /  _ \  \/  /
#   Jukebox    |    |   (  &amp;lt;_&amp;gt; )  \___|    &amp;lt; | \_\ (  &amp;lt;_&amp;gt; &amp;gt; &amp;lt;  &amp;lt;
#   Firmware   |____|_  /\____/ \___  &amp;gt;__|_ \|___  /\____/__/\_ \
#                     \/            \/     \/    \/            \/
# $&lt;/pre&gt;</description>
    <dc:creator>Zahari Yurukov</dc:creator>
    <dc:date>2013-02-20T19:21:51</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10876">
    <title>Rockbox on YP-Z5...</title>
    <link>http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10876</link>
    <description>&lt;pre&gt;Hello guys!

It's me again, this time working on native stuff ^^
Here a self-explanatory screenshot telling you that work has been done on a
new target: Samsung YP-Z5!!
This player has a STMP3650 cpu, quite similar to the STMP37xx port by
pamaury, who in fact helped me a lot...Thanks to him, then.
Wiki for more info: http://www.rockbox.org/wiki/SamsungZ5

In the meantime - lot of stuff has still to be done - see the link below :)

https://www.dropbox.com/s/wolr8h2hez1iz07/rockboxZ5.jpg

(Sorry for picture quality + dirty buttons, I bought it in this state :p)

Lorenzo
&lt;/pre&gt;</description>
    <dc:creator>Lorenzo Miori</dc:creator>
    <dc:date>2013-02-19T11:31:45</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10873">
    <title>Call for translations</title>
    <link>http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10873</link>
    <description>&lt;pre&gt;Hi all,

It's that time again!  We have just gone into feature freeze for Rockbox 
3.13, and it would be nice to ship with as many complete translations as 
possible.  It would therefore be great
if any native speakers out there could take this opportunity to update 
the translation of their language.

We have an excellent translation tool available at 
http://translate.rockbox.org, so please head over, follow the 
instructions, and then post the completed translation to gerrit,flyspray 
or the development mailing list.  For any queries please ask on IRC.

We are not doing badly at present with 18 complete translations, 13 good 
translations (&amp;gt;95% translated), 12 normal translations (&amp;gt;50% translated) 
and 4 bad translations (&amp;lt;50% translated), but with your help we can be 
even better!  Some languages appear to be using English strings in 
places, so if you could check yours that would be very helpful.

Thanks in advance,

Alex

&lt;/pre&gt;</description>
    <dc:creator>Alex Parker</dc:creator>
    <dc:date>2013-02-16T12:55:09</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10872">
    <title>Feature freeze for 3.13</title>
    <link>http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10872</link>
    <description>&lt;pre&gt;Hi all,

We are now in feature freeze in preparation for 3.13.

The freeze is planned to be for a week, so please try and fix as many 
bugs as possible in that time.  I will post RC builds in a day or two to 
aid bug hunting.

Thanks,

Alex

&lt;/pre&gt;</description>
    <dc:creator>Alex Parker</dc:creator>
    <dc:date>2013-02-16T12:52:29</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10869">
    <title>RFC new line API</title>
    <link>http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10869</link>
    <description>&lt;pre&gt;Hello guys,

I'm working on a new line print API in apps that's supposed to replaces 
most of lcd_puts_* and lcd_putsxy_*.

The lcd_puts* became really messy and it still doesn't support scrolling 
properly (not at all for pixel based functions). The rework I'm working 
on will hopefully be simplified and fix scrolling, while allowing more 
control over the line style and contents.

My motivation is to properly implement [1] (line separator in lists). 
This line separator cannot be properly implemented just in apps because 
scrolling draws over it, and scrolling is entirely in firmware and calls 
only firmware function. To not further complicate lcd_puts* a rework is 
needed.

My idea is a having a single function:

put_line(int x, int y, struct line_desc *desc, const char *fmt, ...).

- x, y are the position of the line (in pixels!).
- struct line_desc defines other properties the line: style (for line 
selectors, and the line separators mentioned above), scrolling, line 
height and multiline information.
-&lt;/pre&gt;</description>
    <dc:creator>Thomas Martitz</dc:creator>
    <dc:date>2013-02-15T21:30:34</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10863">
    <title>Sansa Clip+ SPI/SSP Support</title>
    <link>http://comments.gmane.org/gmane.comp.systems.archos.rockbox.devel/10863</link>
    <description>&lt;pre&gt;Hey,

According to the Datasheet linked in the Wiki, the SoC used in the Sansa 
Clip+ has an SPI/SSP Port.  I already checked that its balls are not muxed 
with any GPIO pins or other  peripherals. Has anybody ever tried to map all 
the pins that are broken out  SOMEWHERE on the PCB? Or tried to identify the 
remaining few ICs on the  board? I would be grateful for any additional 
documentation on the available  hardware features. If there is none, I will 
start probing myself maybe next  weekend and see what I can find.

Another thought that crossed my mind was using the µSD-pins for SPI, but 
 unfortunately the way I read the datasheet this would mean bit-banging 
 everything.

I'm currently looking for a way to interface one of those cheap 2.4Ghz 
Transcievers from Nordic Semi 
 (http://www.nordicsemi.com/eng/Products/2.4GHz-RF/nRF24L01P) to an ARM 
 system capable of Audio Playback/Recording. My first shot was using an 
 STM32F4-DISCOVERY board, but the open source tools available for on-chip 
 debuggin&lt;/pre&gt;</description>
    <dc:creator>Bohnens Carsten</dc:creator>
    <dc:date>2013-02-13T09:41:27</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.systems.archos.rockbox.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.systems.archos.rockbox.devel</link>
  </textinput>
</rdf:RDF>
