Weitergeleitete Nachricht
Return-Path:
Delivered-To: thomas.mart...@mail.tmartitz.de
Received: from director-06.heinlein-hosting.de ([10.192.2.32]) (using
TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by
dobby23a.heinlein-hosting.de with LMTPS id
Am 10.09.18 um 21:45 schrieb Olivier Kaloudoff via rockbox-dev:
Hi list !
I've been using rockbox in the past and enjoyed it much.
Today I'm fan of an obsolete platform ... BlackBerry 10. At least one
of their phone has great audio quality, the Q5. He has an audio Line
Out, as well.
As
Am 20.04.2017 um 14:23 schrieb Björn Stenberg via rockbox-dev:
Hello all patient devs.
Let me make a case for Phabricator, see https://www.phacility.com
We use Phabricator at work for a pretty large code base for about one
and a half years now, and we truly appreciate it. It offers most
Am 14.06.2015 um 22:22 schrieb Marcin Bukat via rockbox-dev:
Google pulled the plug from openid 2.0. This means no gerrit access
for many who used google account to authenticate. Are there any plans
to remedy this situation? I guess upgrading gerrit should bring new,
supported by bigG
Am 22.02.2015 um 21:15 schrieb Thomas Jarosch:
Hi Thomas (kugel),
Am Sonntag, 15. Februar 2015, 23:45:48 schrieb Thomas Martitz:
The below commit isn't necessary.
buflib buffers can be passed to yielding functions just fine. Problems
only arise if the are concurrent allocations, for example
The below commit isn't necessary.
buflib buffers can be passed to yielding functions just fine. Problems
only arise if the are concurrent allocations, for example if two threads
allocate from the same context simultaneously or if the callee does it's
own allocations. This can't happen in the
Am 08.02.2015 um 00:21 schrieb Mike Giacomelli:
This commit should not have been made without discussion because:
1) We had previously rejected it
2) We generally try to avoid giving users frivolous hardware settings.
When it comes to audio we generally try to expose all hardware
Am 29.11.2014 um 09:55 schrieb Andrey Ryabinin:
[Duplicating [3] in mailing list for wider audience and discussion.]
Commit 7d1a47cf (Rewrite filesystem code (WIP)) introduced
regressions ([1],[2]) on several rk27xx targets, making them nearly unusable.
Due to size of this change it's nearly
Am 05.08.2014 um 09:13 schrieb Marcin Bukat:
+1
2014-08-04 22:49 GMT+02:00 Paul Louden paulthen...@gmail.com
mailto:paulthen...@gmail.com:
As an iFP799 owner, let it rest. :)
On Aug 4, 2014 3:27 PM, Michael Sevakis jethea...@sbcglobal.net
mailto:jethea...@sbcglobal.net wrote:
Am 05.07.2014 10:30, schrieb Jonathan Gordon:
On 4 July 2014 16:21, Thomas Martitz ku...@rockbox.org
mailto:ku...@rockbox.org wrote:
Why do you except this to fix skin issues? It only _adds_ fragile
pointer management. What's wrong with the current aproach?
What's wrong
Am 03.07.2014 15:21, schrieb Jonathan Gordon:
Hi all,
Over the last few days I've been working on redoing how the skin
engine manages its buffers. My goal is to finally get rid of all the
semi-random skin issues and this is the first step.
Why do you except this to fix skin issues? It
Am 18.06.2014 08:13, schrieb Marcin Bukat:
Hi rockboxers!
There have been long time since we did 3.13. We are in the state where
first thing we advice when someone pops up with problem is to install
development build. Moreover there are quarrels among devs comming from
the fact that we are
Am 18.06.2014 08:35, schrieb Marcin Bukat:
The synopsys patch depends on g#842 which may have side effects on all
targets with software usb. In theory we could add it to RC builds and
wait for testers but realistically RC builds gets next to no testing.
RC builds actually do get testing,
Am 18.06.2014 11:41, schrieb Alex Parker:
On 18/06/14 07:13, Marcin Bukat wrote:
Hi rockboxers!
Now the question
comes - do we still have release manager (Alex?)
Marcin Bukat (wodz)
Hi guys,
A release sounds like a great idea, it is well well overdue (sorry!).
As is noted later in this
Am 22.04.2014 11:18, schrieb Marcin Bukat:
For me 28-29 turns to be problematic as I may be coming back on Friday
from business trip. Counting on plane follow the schedule is risky. I
still think 14-15 is not that bad considering that Amaury is willing
to come on that date. We can also move
Hey,
I would totally love to attend. Obviously it depends on the dates. Thanks for
volunteering to host!
Best regards
Am 09.02.2014 13:06, schrieb Frank Gevaerts:
Hi all,
When rockbox started about twelve years ago, the Archos Jukebox was
still a shiny new device, only slightly outclassed by the Recorder with
its wonderful bitmap display.
Rockbox pushed these devices far beyond what anyone could have imagined
Am 12.02.2014 12:02, schrieb Marcin Bukat:
I also agree that 3.14 will not offer significant new features -
in fact some was removed so it keeps building - so that 3.13
should be the recommended build even if we made a 3.13 for them.
We should continue to offer this build for
Am 22.01.2014 09:49, schrieb Marcin Bukat:
Perhaps I am missing something but why buflib-on-buflib is used actually?
2014/1/21 Thomas Martitz ku...@rockbox.org mailto:ku...@rockbox.org
Hello folks,
I wanted to request comments on my talk rewrite on gerrit[1].
For this who
Hello folks,
I wanted to request comments on my talk rewrite on gerrit[1].
For this who haven't heard about it yet I'll summarize what it is about:
I found that the cache management for TALK_PARTIAL_LOAD is immensely
inefficient. It allocates 64 slots for talk clips, each as big as the
Am 05.01.2014 15:14, schrieb Amaury Pouly:
I'm pleased to announce that Rockbox successfully played its first
track on the Creative ZEN X-Fi Style: PrototypeRaptor - Drive Hard
Awesome, nice work!
The port was completely trivial except for a little quirk with the MBR
handling, so I did it
Am 05.01.2014 20:23, schrieb Amaury Pouly:
Look for HAVE_SPEAKER. A framework for speakers (if you can even
call that framework) has been added for the Onda series. So
Rockbox can support speakers.
That is true but it is not very good: one cannot choose when to use
the speaker
Am 14.04.2013 19:46, schrieb Thomas Martitz:
Am 15.02.2013 22:30, schrieb Thomas Martitz:
My idea is a having a single function:
put_line(int x, int y, struct line_desc *desc, const char *fmt, ...).
I've worked on this further, and it's coming along nicely. I've put my
current work
Am 23.12.2013 14:53, schrieb benjamin brown:
On Mon, Dec 23, 2013 at 3:56 AM, Thomas Martitz ku...@rockbox.org
mailto:ku...@rockbox.org wrote:
Am 14.04.2013 19:46, schrieb Thomas Martitz:
Am 15.02.2013 22:30, schrieb Thomas Martitz:
My idea is a having a single
Am 02.12.2013 03:16, schrieb Jonathan Gordon:
Sounds pretty cool!
(Possibly a dumb question), Are you only targeting *as App type
builds or will this be used on (i.e) ipods with the rockbox core?
App-type builds, in particular as a library with an OS-native (or QT)
UI. I don't have plans
Am 02.12.2013 11:35, schrieb Björn Stenberg:
Thomas Martitz wrote:
Therefore I propose that we relax the typedef rule and allow
typedefs for integral types (only) when reasonable. This would
basically be adopting the Linux kernel guideline w.r.t. to typedefs,
There are times when typedefs
Hey folks,
this is not the usual kind of Ladies and Gentlemen mail. Instead of a
new port I have managed to get Rockbox play sound in a new environment.
What I am working on is to to detach the playback core (including
codecs, buffering and playlists) from the GUI and legacy OS-like
Hello,
as you know we have a no typedef rule in our guidelines. However there
are a few problems with it when applied to integral types:
* Portability is reduced, for example we use unsigned for thread ids but
pthread uses unsigned long (I have some work where we can use pthreads,
at least
Am 29.11.2013 09:27, schrieb Thomas Martitz:
Hello,
as you know we have a no typedef rule in our guidelines. However
there are a few problems with it when applied to integral types:
* Portability is reduced, for example we use unsigned for thread ids
but pthread uses unsigned long (I have
Am 29.11.2013 12:11, schrieb Bertrik Sikken:
...
Therefore I propose that we relax the typedef rule and allow typedefs
for integral types (only) when reasonable. This would basically be
adopting the Linux kernel guideline w.r.t. to typedefs, except they
allow typedefs for totally opaque objects
Am 21.10.2013 17:13, schrieb Amaury Pouly:
I'm pleased to announced that Rockbox successfully played its first
tracks on the Creative players:
Creative ZEN Mozaic: Bonobo - Black Sands - Prelude
Creative ZEN: Al Jarreau - Boogie Down
Creative ZEN X-Fi: Chill Carrier - Beautiful Flow
Awesome
Am 27.06.2013 22:26, schrieb Peter D'Hoye:
Reminder:
Looks like Rockbox DevCon will be helt 14-15 september in Gent, Belgium.
Please mark your presence if you intend to come and if you want to use
the hotel
Looks like there will be no devcon this year :( According to the wiki
you have
Am 05.06.2013 11:13, schrieb Amaury Pouly:
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
Am 07.06.2013 14:07, schrieb Amaury Pouly:
2013/6/7 Thomas Martitz ku...@rockbox.org mailto:ku...@rockbox.org
Am 07.06.2013 13:49, schrieb Amaury Pouly:
2013/6/7 Marcin Bukat marcin.bu...@gmail.com
mailto:marcin.bu...@gmail.com mailto:marcin.bu...@gmail.com
Am 08.04.2013 22:54, schrieb Frank Gevaerts:
On Tue, Feb 12, 2013 at 09:45:30PM -0700, Austin Appel wrote:
So, I guess I will make this short: do we want to make the push to
do GSoC again this year or not?
So we did apply, but unfortunately we weren't accepted this time.
Oh, that's
Am 27.03.2013 19:57, schrieb Frank Gevaerts:
On Tue, Feb 12, 2013 at 09:45:30PM -0700, Austin Appel wrote:
So, I guess I will make this short: do we want to make the push to
do GSoC again this year or not?
What I've seen so far in this thread is several idea *titles*, but
nothing with actual
Am 28.03.2013 18:59, schrieb Thomas Martitz:
Am 27.03.2013 19:57, schrieb Frank Gevaerts:
On Tue, Feb 12, 2013 at 09:45:30PM -0700, Austin Appel wrote:
So, I guess I will make this short: do we want to make the push to
do GSoC again this year or not?
What I've seen so far in this thread
Am 19.03.2013 16:16, schrieb Amaury Pouly:
2013/2/13 Austin Appel scorch...@gmail.com mailto:scorch...@gmail.com
So, I guess I will make this short: do we want to make the push to
do GSoC again this year or not?
See this email for the longer version of this email (minus the
Am 20.02.2013 13:33, schrieb Jonathan Gordon:
On 20 February 2013 22:34, Thomas Martitz ku...@rockbox.org
mailto:ku...@rockbox.org wrote:
I start with list.c because that's the most extensive user, but
other screens can follow easily, e.g. various plugins. The API
that I
Am 18.02.2013 00:50, schrieb Jonathan Gordon:
OK, so its clear I (and wodz) misunderstood, do you mind please
explaining exactly what you're doing again to clear it up? I
don't understand what the point of having a (almost?) wrapper around
lcd_puts* in apps/ if really the only place it is
Am 16.02.2013 10:46, schrieb Jonathan Gordon:
On 16 February 2013 08:30, Thomas Martitz ku...@rockbox.org
mailto:ku...@rockbox.org wrote:
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
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
Am 13.02.2013 23:25, schrieb Amaury Pouly:
I'm not sure if this is a value idea for GSoc, it's probably not
enough but I think it would worth improving the touchpad code. The
fuze+ is one example of device with a touchpad but there are
potentially others. The possibilities of a touchpad a
Am 13.02.2013 05:45, schrieb Austin Appel:
So, I guess I will make this short: do we want to make the push to do
GSoC again this year or not?
See this email for the longer version of this email (minus the
decided not to apply bit...):
Karl Kurbjun kkurb...@gmail.com schrieb:
Hey all,
I am in the process of cleaning up some old projects and I have a
couple of
development devices that I no longer need for so I thought I would see
if
there is interest here.
The first is a Gigabeat F with JTAG and UART soldered out the side
Am 24.12.2012 01:05, schrieb Mike Giacomelli:
Has anyone successfully cross compiled rockbox for the raspberry pi,
or any other ARM linux system?
I'd like to be able to run the codeclib, or even the UI sim on my new
pi in order to troubleshoot ARM asm code. Looking online, compiling
on
Am 07.11.2012 10:11, schrieb Stefan Seyfried:
Hi all,
I'm new to rockbox development, so bear with me if I'm violating
the mailing list etiquette etc.
On my sansa clip+, there is a quiet, ticking noise on weak fm radio
channels.
I found out that this is probably due to the cpu being woken up
Am 26.10.2012 22:27, schrieb Marcin Bukat:
Hello rockboxers!
TODOs/others:
If this change would be integrated into mainline code it implies a few things:
- SH and MIPS toolchains are too old to support this reliably and need updating.
- It is questionable if this is desired thing for SH. This
Am 15.10.2012 22:01, schrieb Dominik Riebeling:
Am 15.10.2012 21:57 schrieb William Porteous
awesomecomputergeek9...@gmail.com
mailto:awesomecomputergeek9...@gmail.com:
when i try to update manually, it tries to download
rockbox-sansaclipplus-3.11.2.zip... tried installing, and RB says it
Am 15.10.2012 22:24, schrieb Dominik Riebeling:
On Mon, Oct 15, 2012 at 10:06 PM, Thomas Martitz ku...@rockbox.org wrote:
I guess the problem is that he gets 3.11.2 instead of 3.12.
If he installs manually it's up to him what he installs. So no
possibility for a surprise here. Manually
Am 15.10.2012 22:53, schrieb Alex Parker:
On 15/10/12 21:48, Thomas Martitz wrote:
I don't think we should turn it on by default.
a) It imposes quite a CPU load on affected files, since it requires more
DSP processing (in contrast to just replay gain).
Well according to Torne
Am 15.09.2012 15:36, schrieb Frank Gevaerts:
On Thu, Sep 13, 2012 at 09:29:48PM +0200, Marcin Bukat wrote:
The big difference here is that USB on AMSv2 was never truly stable
and as such we do not have stable build to offer. So the only option
is to disable USB in release branch IMO.
I
Am 22.08.2012 02:37, schrieb Jonathan Gordon:
On 22 August 2012 00:50, Bertrik Sikken bert...@sikken.nl wrote:
The archos recorder build has tipped over the limit for size, and now the
autobuild always fails.
The tipping point was commit bd6e6ed but the code has been growing
steadily so I
Am 07.08.2012 04:24, schrieb Mike Giacomelli:
Hi Everyone,
I've committed the new disk logging system. Its now enabled for all
devices, but requires developers to use it to be really useful. That
means updating code you're working on to output useful debug
information. To help with this the
Am 06.07.2012 23:53, schrieb Mike Giacomelli:
We can leave the actual logf code in git, and just convert the stuff
that makes sense over to the new system.
Any log to disk would trigger Jonas' storage-related problems. I guess
he asks if a read-only build would be possible.
Best regards.
Mike Giacomelli giac2...@hotmail.com schrieb:
Can this be turned off? I am hunting issues which relate to disk access,
and I get freezes upon writing / reading in some cases.
Turning this off would result in the system we currently have. If you
want that system, just use LOGF directly and
Am 29.06.2012 17:53, schrieb Bertrik Sikken:
Am 25.06.2012 00:01, schrieb Jacob Mansfield:
Hi All,
I just noticed that my Sansa Fuze errors with an 'Undefined
instruction at 0830' when removing the USB cable. not a major
problem, as holding the power button for about 15 seconds resets the
Am 29.05.2012 22:11, schrieb Frank Gevaerts:
* Do we want one id per target (I think ideally we do)? Or even one id
per main protocol (so we'd use e.g. a different id for MSC than for
MTP (whenever we get MTP support)) (this would mosy probably be asking
too much from the openmoko
Am 29.05.2012 18:34, schrieb Rafaël Carré:
Without -g:
make -j8 293,60s user 17,61s system 690% cpu 45,075 total
$ du -chs .
34M .
With -g:
make -j8 321,22s user 19,88s system 688% cpu 49,556 total
$ du -chs .
99M .
My SSD will not like this :'( I'm also suprised compile time is
Am 17.04.2012 09:34, schrieb Nick Peskett:
On 16/04/2012 12:32, Richard Fröhning wrote:
So I reverted the sleeptimer duration to an int menu and added a menu
point Run Sleep Timer (bool),
which starts/stops the timer duration and resets it - if started, and
runs the the StartOnBootTimer if
Am 10.03.2012 22:37, schrieb Michael Sevakis:
The least invasive way to fix this bug would probably be to figure out
if I2C is already in use when trying to read the hold switch in the
tick
task, and if it is just skip updating the hold switch status for
that tick.
Really a nice hack, just
Am 10.03.2012 22:55, schrieb Michael Sparmann:
On the other hand this might be responsible for quite a bit of CPU
load. Let's say 300us every 10ms, that's a whopping 3% of CPU load for
the hold switch polling alone! Does it really need to be done that
often? Might cause quite some battery
Am 08.03.2012 08:52, schrieb Marcin Bukat:
Tick tasks are run from ISR. There is absolutely no need to read keys
in ISR IMO, reading in ISR gives no benefits in this case.
Less code and indirection is a benefit.
How do you propose to do keyreading instead?
Best regards.
Am 06.03.2012 08:01, schrieb Marcin Bukat:
Please don't do such an ugly thing. An extra target specific thread,
contained in the target tree, is perfectly fine (there are other targets
doing similar things).
The whole point is that its pretty dumb to read keys from ISR and this
is not target
Am 10.02.2012 21:44, schrieb Frank Gevaerts:
Hi all,
If we want to apply to participate again to the Google Summer of Code
2012, we'll need more project ideas and more mentors.
No replies. I guess the desire to participate in gsoc isn't strong this
year.
I would throw in an idea or two,
Am 27.02.2012 11:30, schrieb Torne Wuff:
I absolutely agree; while *our* definition of unstable includes is
missing USB support, the consistent surprise users demonstrate when
they find out is evidence enough that that definition is not obvious
:)
That's not quite right. We allow targets
Am 26.02.2012 01:03, schrieb Frank Gevaerts:
Since USB was enabled on trunk to evaluate how well USB works, without
knowing if it will even be enabled in the next release, I must say I
fail to understand why mkamsboot got changed.
I agree (in hindsight, I too haven't thought of this issue when
Am 04.02.2012 02:17, schrieb Boris Gjenero:
Hello All!
I created a test build for PP502x based devices. You can download it
from:
http://dl.dropbox.com/u/16662598/Rockbox/pp502x_cache_test/index.html
FWIW, we have a test build subforum:
http://forums.rockbox.org/index.php/board,53.0.html
Am 02.02.2012 21:08, schrieb Marcin Bukat:
2) Relax the requirements for target to become stable. I mean we could
agree on minimal subset of plugins (and documentation in manual)
needed for a given port to fulfill stable criteria. Rockbox is about
playing music and not playing games and watching
Magnus Holmgren magnus...@gmail.com schrieb:
Hi,
I don't understand why, but this line in
lib/arm_support/arm_support.make breaks
Fuze V2 builds for me:
LIBARMSUPPORT := $(BUILDDIR)/lib/libarm_support.a
(Change-Id: I34526a015357e36ffd612bf2fabf78a0354066ca)
I get this error when linking a
Am 24.12.2011 20:40, schrieb Mike Giacomelli:
I wasn't proposing removing HWCODEC from rockbox, I was proposing
creating two branches, one for SWCODEC devices and one for both types
of devices. Development would continue in both, both would be built on
every change, released every 4 months,
Am 04.01.2012 17:05, schrieb Jean-Louis Biasini:
Hi all,
1) what I do for now
I'm working on keymaps and manual for the new fuze+ port. I suppose
that you already know the kind of harrassing boring task this can be.
If not you may have a look to the kind of patch that one has to provide:
for
Am 29.12.2011 12:01, schrieb Bertrik Sikken:
On 21-12-2011 7:53, Boris Gjenero wrote:
With -Wmissing-declarations, gcc can warn about non-static global
functions and data without a previous declaration. What do others think
about the idea of enabling the warning for the core, after some
Hello,
I just stumbled upon
http://www.rockbox.org/wiki/TargetStatus#New_Platforms_Currently_Under_De and
the red notice that ipod 1g2g have a serious issue. The issue appears
(to me as a non-owner, anyway) fixed by FS#8778.
Does anyone know more about this? If not, I would tend to commit
Am 24.12.2011 13:01, schrieb Jens Arnold:
Advantages:
***Greatly simplify large parts of the code for SWCODEC targets (see
JdGordon's forum posts in rockbox general)
I fail to see how forking HWCODEC will actually simplify SWCODEC code.
All it does is that it removes a number of #ifdefs
Am 24.12.2011 16:46, schrieb Dominik Riebeling:
How often have others by making / unifying things? Why is it a
positive exeption if someone who is mainly inactive these days
starts working on some stuff again? I find such a positive exception
statement pretty inappropriate.
An exception of
Am 24.12.2011 20:39, schrieb Torne Wuff:
Isn't the serious issue in question we can't power off? :)
Not according to the wiki page. Footnote 1 is about the scrollwheel problem.
I can't find any mention of that we can't power off problem there. Is
that documented somewhere? I don't think I
May I propose a 3rd alternative, instead?
As you mentioned, the sleep timer has more in common with the idle
poweroff. So, for your new feature, how about merging idle power off and
sleep timer to an inactivity timer, with the additional option of
whether to run during playback (yes/no). Then
Am 15.12.2011 00:21, schrieb Mike Giacomelli:
The alternative I think is to keep both together indefinitely while
accepting that people may not want to upgrade from what they're
already running. I think this is a bad way forward because in
practice if people do not upgrade, then we have left
Am 08.12.2011 22:05, schrieb Peter Lecky:
make: *** No rule to make target
`/rockbox/build/apps/bitmaps/native/rockbox/bui
ldlogo.128x42x1.o', needed by `/rockbox/build/rockbox.elf'. Stop.
No idea where this comes from, perhaps an (accidental) local change or
whatever, but we don't
Am 04.12.2011 17:25, schrieb Boris Gjenero:
File functions have the same system, via firmware/include/file.h.
However, the defines for directory functions simply define names, and
defines for the file functions use function-like macros such as:
# define creat(x,m) sim_creat(x,m)
In this
Am 01.12.2011 22:47, schrieb Michael Sevakis:
Is that a size we still can live with?
I forgot to ask: were you proposing to increase it for just maemo or
for all targets? I wouldn't recommend doing the latter. In fact it
probably wouldn't compile on many targets anyway and also scrollwheels
Am 02.12.2011 07:27, schrieb Thomas Martitz:
Am 01.12.2011 22:47, schrieb Michael Sevakis:
Is that a size we still can live with?
I forgot to ask: were you proposing to increase it for just maemo or
for all targets? I wouldn't recommend doing the latter. In fact it
probably wouldn't
Am 30.11.2011 13:35, schrieb Thomas Jarosch:
Hi,
I just noticed a performance regression with rockbox 3.10
compared to rockbox 3.9 on the Nokia N900.
FWIW, IMO you shouldn't use the release versions/terms for RaaA/Maemo as
3.10 (or any previous release) isn't released for it. Releases apply
Am 28.11.2011 23:39, schrieb Sebastian Aus:
Hello.
I decided to learn plugin development and I'm following the tutorial.
The issue is that I would like to compile just the plugin I'm working
on, to get the .rock file, and not the whole rockbox. How would I do this?
make
Date: 2011-11-29 05:56:42 +0100 (Tue, 29 Nov 2011)
New Revision: 31089
Log Message:
FS#12414 : Fix directory functions in plugins on targets which HAVE_DIRCACHE.
In rockbox_api, PREFIX( ) is removed around directory functions because that's
now handled in directory header files. Thanks to Fred
Am 28.11.2011 10:38, schrieb Jonathan Gordon:
I would like:
- some WPS to Database action (we have one to browser, one to playlist)
The keymap is the wrong place for this. If you want to provide
wps-file and wps-database it should be a user configurable option
for all targets.
Well, the
Am 24.11.2011 21:50, schrieb Thomas Martitz:
So in the end they look better and are easier to maintain. Thus,
unless there's opposition I'm going to commit them by this weekend.
Done that. I would love if someone with the required skills could create
a greyscale version of the new icons
Hello folks,
I'm planning to commit some new icons for color displays, with the main
purpose to add better looking (by alpha blending) and bigger (e.g. for
RaaA or other higher res screen like ipod video) ones.
These are transparent images. Therefore they use more memory (25%) and
are a bit
Am 17.11.2011 21:33, schrieb Dominik Riebeling:
On Thu, Nov 17, 2011 at 8:52 PM,mai...@svn.rockbox.org wrote:
Date: 2011-11-17 20:52:59 +0100 (Thu, 17 Nov 2011)
New Revision: 31011
Log Message:
Remove sim_tasks from the sdl application build.
This unfortunately removes the screendump
Am 17.11.2011 22:08, schrieb Thomas Martitz:
that's press (alt+)print key
That should read that's *not* just press (alt+)print key
Am 16.11.2011 09:02, schrieb Jonathan Gordon:
The task has been open for 5 years, so I'm obviously not asking about
changes in the last month. Is there any reason the piezo driver part
has not been accepted so far?
I don't know what was before 2010, but I looked at it in january 2010
(see my
Am 16.11.2011 05:33, schrieb Jonathan Gordon:
Hey all,
Does anyone know why http://www.rockbox.org/tracker/task/5111 is not in svn?
Jonathan
Last time I looked I complained that it didn't integrate with the
software keyclick. What's the situation there now?
According to your comments you
Am 13.11.2011 13:57, schrieb Jonathan Gordon:
3rd time lucky, this one really compiles
I hope you plan on replying to the concerns before committing.
Best regards.
Am 13.11.2011 15:32, schrieb Frank Gevaerts:
On Mon, Nov 14, 2011 at 01:13:47AM +1100, Jonathan Gordon wrote:
On 14 November 2011 01:09, Frank Gevaertsfr...@gevaerts.be wrote:
If someone could come up with a way to make OFFSETTYPE() actually *do*
something (a clever way to do type checking,
and best regards,
Thomas Martitz
Am 08.11.2011 14:17, schrieb Jonathan Gordon:
I honestly didnt think it would be this simple! Attached is the
changes removing all dynamic pointers from the skin engine!
Very nice to see it can be done! Good work.
I'm not entirely sure what to do about the conversion macros. I am
going to
Am 06.11.2011 16:24, schrieb Jonathan Gordon:
Three macros and a typedef have been added.
SKINOFFSETTOPTR() and PTRTOSKINOFFSET() convert between the offset and
the real pointer. I originally wanted to put the type in the first
macro and use that instead of void* but not sure if that is really
Am 05.11.2011 11:47, schrieb Alex Parker:
Hi guys,
So, FS#12325, FS#12337 and FS#12279 are marked as being fixed which is
good news, leaving FS#12310 outstanding as a blocker.
My feeling is that it would be handy to get that fixed before
branching, what do people think?
I tend to
Am 27.10.2011 09:31, schrieb Björn Stenberg:
FS#12310 - Crash when inserting USB while playback (since r30097)
FS#12325 - e200v1 screen corruption after USB connection since r30475
FS#12337 - r30773 breaks all skin fonts
FS#12279 - Sansa Clip+: Music playback is returned to the head when wps is
1 - 100 of 559 matches
Mail list logo
