headers
Tony Lenox | 1 Dec 2005 22:58
Picon

RE: sound scaling patch

> And the forth: "lower the value I'm *not* currently changing" 
> so that you can 
> drive up the bass to max and thus have the volume lowered, 
> but then when you 
> switch to the volumne and raise that to the max you get the 
> bass lowered...

Question is in this case, btw: while switching between options to this one 
- what should be the behaviour? (as you are not modifying any sound
settings)
If you do nothing then you end up with whatever you had selected 
before (therefore incosistent if you scrolling via options using up or
down).

Anton.
Permalink | Reply | 0 comments |
headers
Daniel Stenberg | 2 Dec 2005 08:56
Favicon

making tools from build dir only?

Hi

Is there anyone who would object if I made the tools building only available 
by running make (or make tools) in the build dir?

It would then only build the tools necessary for the particular target you are 
building.

We get more and more tools that are made for specific targets (archos, iaudio, 
iriver, ipod all have their own set)...

--

-- 
  Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Permalink | Reply | 1 comment |
headers
Manuel Dejonghe | 2 Dec 2005 09:32
Picon
Gravatar

Re: making tools from build dir only?

On 12/2/05, Daniel Stenberg <daniel <at> rockbox.org> wrote:
> Is there anyone who would object if I made the tools building only available
> by running make (or make tools) in the build dir?
>
> It would then only build the tools necessary for the particular target you are
> building.
>
> We get more and more tools that are made for specific targets (archos, iaudio,
> iriver, ipod all have their own set)...

Good idea.
I had to modify my makefile one day lately because an unneeded tool
could not be build and so was the build itself not building.

lImbus
Permalink | Reply | 0 comments |
headers
Daniel Stenberg | 2 Dec 2005 16:34
Favicon

Re: making tools from build dir only?

On Fri, 2 Dec 2005, Bluechip wrote:

> How about getting configure to create a makefile which, instead of building 
> ALL tools, builds the correct tools according to the platform selected?

That is exactly the outcome of this change of mine (that already is 
committed).

--

-- 
  Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Permalink | Reply | 0 comments |
headers
Bluechip | 2 Dec 2005 16:28
Picon

Re: making tools from build dir only?

At 08:32 02/12/2005, you wrote:
>On 12/2/05, Daniel Stenberg <daniel <at> rockbox.org> wrote:
> > Is there anyone who would object if I made the tools building only 
> available
> > by running make (or make tools) in the build dir?
> >
> > It would then only build the tools necessary for the particular target 
> you are
> > building.
> >
> > We get more and more tools that are made for specific targets (archos, 
> iaudio,
> > iriver, ipod all have their own set)...
>
>Good idea.
>I had to modify my makefile one day lately because an unneeded tool
>could not be build and so was the build itself not building.
>
>lImbus

How about getting configure to create a makefile which, instead of building 
ALL tools, builds the correct tools according to the platform selected?

BC
Permalink | Reply | 1 comment |
headers
ian douglas | 3 Dec 2005 01:58
Picon

patched H300 firmware

Reading through the instructions, it appears that only windows users can 
run the utility that patches the H300 firmware to be able to load the 
Rockbox code?

Can someone supply me with a v1.28 or 1.29 english (EU i guess?) hex 
file so I can test it out and start playing with code to help out with 
this project?

Also, the NODO.txt file that exists in the .rockbox folder once unpacked 
says "The mp3-decoding hardware cannot decode ogg" - does that mean it 
cannot play ogg files, or just that it cannot convert files on the unit 
itself?

Thanks, looking forward to finally playing around with the code this 
weekend, see if I can help with making some forward progress.
--

-- 
Ian Douglas
blogs & photos: http://www.w98.us/
Permalink | Reply | 1 comment |
headers
Linus Nielsen Feltzing | 3 Dec 2005 02:15
Picon
Favicon
Gravatar

Re: patched H300 firmware

ian douglas wrote:
> Reading through the instructions, it appears that only windows users can 
> run the utility that patches the H300 firmware to be able to load the 
> Rockbox code?
> 
> Can someone supply me with a v1.28 or 1.29 english (EU i guess?) hex 
> file so I can test it out and start playing with code to help out with 
> this project?

What operating system do you use? You can always patch the firmware 
yourself with the mkboot tool. It's all explained here:

http://www.rockbox.org/twiki/bin/view/Main/IriverBoot

> Also, the NODO.txt file that exists in the .rockbox folder once unpacked 
> says "The mp3-decoding hardware cannot decode ogg" - does that mean it 
> cannot play ogg files, or just that it cannot convert files on the unit 
> itself?

That's an old file from the Archos days that we forgot to remove. It 
only applies to the Archos.

Linus
Permalink | Reply | 0 comments |
headers
Jonathan Gordon | 4 Dec 2005 00:37
Picon
Gravatar

(hopefully useful) unfinished colour bmp loading

hey,
i dont know how usefull this will be, maybe you can get it working.
ive attached the beginging of colour bmp loading for the h300.. really
all it is is the code form bmp2rb made to work ont he player. problem
is it loads a mostly black screen.
hopefully some1 can finish it (im going overseas for 6 weeks tomorow
and unfortunatly cant finish it before then :( )
Attachment (bmp.rar): application/x-rar-compressed, 4538 bytes
Permalink | Reply | 0 comments |
headers
Magnus Holmgren | 4 Dec 2005 14:41
Picon
Picon

Makefile cleanup

Hi,

I've been rummaging around the Makefiles a bit lately (mainly the for
codecs) and I've noticed a couple of things that could be improved:

* Several codec makefiles contain a rule like this:

   $(OBJDIR)/<codec>/%.o: $(APPSDIR)/codecs/≤codec>/%.c

   But it doesn't match, so the build rule in make.inc is used instead.
   Thus, all the "extra" stuff in the $(CC) command of the rule isn't
   needed and can be removed. It also means that the only thing the
   rule really adds is allowing for a different "echo" line. It also
   means that at least some codecs (e.g., liba52) are built using -O
   rather than the intended -O2.

   So, what to do? Correct the rules and remove the uneccessary stuff,
   or remove the rules completely?

* codecs/Makefile creates a dependency file, but it isn't used,
   afaict. Should it be used or removed completely?

* codecs/Makefile define OUTPUT when invoking the codec makefiles.
   Many of the codec makefiles define OUTPUT too (and to the same
   value). Clearly, two definitions is one too many, but which should
   be removed? I'd say the ones in the codec makefiles.

* I've found one thing that makes "make clean" slow on Cygwin:
   dependency generation. Adding a "ifneq ($(MAKECMDGOALS),clean)"
   around each depenecy file include speeds things up. Is it okay if I
(Continue reading)

Permalink | Reply | 3 comments |
headers
Tony Lenox | 4 Dec 2005 14:55
Picon

RE: Makefile cleanup

I also noticed that FAAD (and only FAAD) is being made every time there is a
significant change in apps/firmware.
Is it really needed? (my guess that its referencing some headers it
shouldn't have referenced)

Anton.

> -----Original Message-----
> From: rockbox-dev-bounces <at> cool.haxx.se 
> [mailto:rockbox-dev-bounces <at> cool.haxx.se] On Behalf Of Magnus Holmgren
> Sent: Sunday, December 04, 2005 1:42 PM
> To: Rockbox development
> Subject: Makefile cleanup
> 
> Hi,
> 
> I've been rummaging around the Makefiles a bit lately (mainly the for
> codecs) and I've noticed a couple of things that could be improved:
> 
> * Several codec makefiles contain a rule like this:
> 
>    $(OBJDIR)/<codec>/%.o: $(APPSDIR)/codecs/≤codec>/%.c
> 
>    But it doesn't match, so the build rule in make.inc is 
> used instead.
>    Thus, all the "extra" stuff in the $(CC) command of the rule isn't
>    needed and can be removed. It also means that the only thing the
>    rule really adds is allowing for a different "echo" line. It also
>    means that at least some codecs (e.g., liba52) are built using -O
>    rather than the intended -O2.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane