• Status Closed
  • Percent Complete
  • Task Type Patches
  • Category User Interface → Themes
  • Assigned To No-one
  • Operating System iPod 5G
  • Severity Low
  • Priority Very Low
  • Reported Version
  • Due in Version Undecided
  • Due Date Undecided
  • Votes 3
  • Private
Attached to Project: Rockbox
Opened by pijulius - 2006-08-29
Last edited by Llorean - 2008-01-16

FS#5900 - Custom WPS Line with x/y/width coordinates and font face/color settings

This patch adds a new tag in your wps which looks like this:

11 = x coordinate
219 = y coordinate
30 = width
1 = userfont1 (this is the font face for this line wich is defined in the wps.cfg)
B8C8E1 = the color for the line

%al is the normal tag for aligning text to the left

NOTE1: It depends on the multifont-userfonts.patch
NOTE2: All values have to be specified none of them is optional.
NOTE3: %s (scrolling tag) is not working yet, but I hope to integrate it soon.


Closed by  Llorean
2008-01-16 14:18
Reason for closing:  Rejected
Additional comments about closing:  

See viewports.

Fix aligned texts to center

gwps-common.c: warning: implicit declaration of function `hex_to_rgb’ hex_to_rgb is defined in setings.c but it seems not to be exported as I cannot find it in settings.h. Do you have any idea for a solution?


More compile errors with current CVS plus only this patch:
CC gui/gwps-common.c
gui/gwps-common.c: In function `format_display’:
gui/gwps-common.c:1332: warning: implicit declaration of function `hex_to_rgb’ gui/gwps-common.c: In function `gui_wps_refresh’:
gui/gwps-common.c:1896: error: `FONT_USER1’ undeclared (first use in this function)
gui/gwps-common.c:1896: error: (Each undeclared identifier is reported only once
gui/gwps-common.c:1896: error: for each function it appears in.)
gui/gwps-common.c:1899: error: `FONT_USER2’ undeclared (first use in this function)
gui/gwps-common.c:1902: error: `FONT_USER3’ undeclared (first use in this function)
gui/gwps-common.c:1905: error: `FONT_USER4’ undeclared (first use in this function)
gui/gwps-common.c:1908: error: `FONT_USER5’ undeclared (first use in this function)
gui/gwps-common.c:1911: error: `FONT_USER6’ undeclared (first use in this function)
gui/gwps-common.c:1914: error: `FONT_USER7’ undeclared (first use in this function)
gui/gwps-common.c:2117: error: structure has no member named `set_custom_width’

The first thing: implicit declaration of function `hex_to_rgb`, ignore it for now, it is a warning anyway, so it works without any problem.

Regarding your compile error, it is because you didn’t apply the multifont and multifon-userfonts patches to your source. I wrote about this see NOTE1. I wanted to make links to the other two patches, but I don’t really know how to place links in this tracker system, and I can’t seem to find a way to link this patch to the other two, I see there is a place for “This task depends upon” but I wasn’t able to add there anything.

Ooo, and another thing, it depends on the custom_display_width patch too, so these are the patches that you need to use this one: #4733 #5901 #5898

The remote (in the simulator) is displaying nothing on
the playback screen if I apply this patch
(together with the multifont, multifont-user and custom_disply_width path)
this happens with all themes. The file list display is ok
Without this single patch (but still with all the others) the remote is
back to normal

Hi Max,
How did you checked this out? did you try to use a tag as specified above?:
please note that it does not support scrolling lines (it will be implemented separattely in the future, so you won’t have any need for it) so if you use %s%alMusic it won’t show up, %s is not supported. The rest should work, but write me if you can’t get it to work. For e.g. try to use one of my themes to check it out, for e.g. jClix or jBlackGlass, both use this feature ti display the texts on the wps.


I dont use any %e in my wps at the moment.
Just want to make sure all others old wps are still working
together with this patch :-)

And still the remote screen in the simulator becomes blank
on the playback screen. Removing the patch and it is back.

Cannot try it on may real X5 because I dont have a remote there

Hmm, I’m not sure but it may be something related to the custom patches that you added to your source, for e.g. you have rewriten the customdisplaywidth to be compatible with the scrollmargin patch, but in this patch I use the set_custom_width which now sets the values for the scroll margin, so it seem like a mess up which is hard to fix, you know, I never planed to use these patches with scrollmargins exactly for this reason.

Sorry, but it seems we really can’t have this patch working together with the scrollmargins patch.

But the remote is not using ANY scroll margins or custom lines right?
And in the main WPS either or scroll margins or custom line
seems to work.

Is the remote working in your build in the simulator?

Both of course together in one WPS will be a problem :-)

I just wrote a basic theme with ONLY custom line
NO scroll margins and the remote is blank

Let me check out if I got it to work with an X5 sim, I just tried to compile it, but I have a problem in the lcd-remote-2bit-vi.c, it seems it’s related to the multifonts patch, I will have a look on it and will get back to you in the next few days.

You need a patch :-)

I finally found out the reson why the remote display is blank
This change in gwps-common.c is the reason


If I comment this single lines the remote is back working

any ideas?

And if I use the function lcd_set_foreground instead
of display→set_foreground it also works

Attached a version that fixes on problem if you switch
between a wps that uses %e and a wps without.

Else the screen layout is wrong because the %e
specific values are still used

Getting an error when trying to compile.

gui/gwps-common.c: In function ‘gui_wps_refresh’:
gui/gwps-common.c:2119: error: too many arguments to function

This is what line 2119 looks like.

display→setmargins(data→line_xpos, data→line_xpos+data→line_width, data→line_ypos);


Change to

display→setmargins(data→line_xpos, data→line_ypos);

If you dont have the scroll_margins patch applied.
Sorry that this slipped into the patch

I was asked from people when scrolling will be added to this :)
From looking into the current scrolling code which is strictly line based
I am a little bit curious how this will be done :)
Do you have allready some implementation ideas how you will do this?

The idea is to use puts_scroll if the width of the text is bigger than the specified area’s width, just I didn’t have the chance to try it out.

but the scroll[] array is line based.
How will this match with custom y-positions?

We will see :) but I’m sure it’s not impossible because the list is already positioned by an Y coordinate and it scrolls without any problem, so just have some patient and I’m sure it will be done somehow.

Hi guys,

As I said that I will do it, I did it :) so here you go, the attached patch adds scrolling capabilities to the customline patch, so now there is no need for scrollingmargins :) (just kidding)

So to use it you have to use the same scrolling line mark as always, for e.g.:

would scroll the line on the x=11 y=219 coordinates within a 100px long area. Please note the “%s” after “%al” which is important/necessary to activate the scrolling option.

It includes a few fixes too, like reseting the margins on wps exit (thanks a lot Max!) and some other fixes.

Wish you the bests!

ps: only platform I tested iPod 4g and 5g (sorry Max, I haven’t had the chance to test it on X5)

Hi Julius!
Can you enlighten me for a moment, because I am thinking about including the patches into my Norbu build:
- If I include this patch and leave out scrollmargins, will the old WPS continue to work? Or is some changing necessary?
- Which additional patches do I need to include, and in which order, to get customline working?
Thanks a lot and all the best


Hi Norbert,

1: This patch does not replace the scrollmargins patch in any way, it just does the some thing with some more options like font face, color and x/y positioning, so if you removed the scrollmargins patch from your build the wps-es would have to be modified to support this patch

2: To make this patch working you would need the followings:

#5898 Custom display width
#4733 Multifont
#5901 Multiple user fonts for using in WPS
and I would suggest the
#5899 Custom List/Menu x/y coordinates and width
but this patch is not a must to have customline working.

NP, you’re welcome! I hope this helps, write me if there is anything.

There was a bug with the list/menu color which was changed to the one used in the last line of the wps, but the attached patch should fix it.


Cool! :-)

Thanks a lot I will try it asap


Sorry guys, the prev patch was malformed so the attached one should be ok.

One problem I noticed with the sim
If I use a WPS with %e and %s
sometimes when switching back to the file browser
still scrolling lines from the WPS are displayed
‘over’ the browser lines

Hi Max,

Could you somehow give me more info on this bug because I can’t seem to reproduce it.

Thanks in advance!

I will try :)

I use the following “very very simple” WPS

%e|5|15|130|4|FFFF00|%al%s%?ia<%ia|%?d2<%d2|(Artist Unknown)» %e|5|35|130|1|FFFF00|%al%pt
%e|5|50|130|3|FFFF00|%al%s%?id<%id|%?d1<%d1|(Album Unknown)» %e|5|67|130|3|FFFF00|%al%s%?it<%it|%fn>
%e|5|85|130|2|FFFF00|%al%sNext: %?It<%It|%Fn>

Displaying the WPS works fine with scrolling but when I switch during playing
to the file browser and lines have been scrolling in the WPS the same
lines scroll in the browser wih the same larger font as in the WPS

BTW:this is my theme cfg file
wps: /.rockbox/wps/Custom_Test.wps
foreground color: FFFFFF
background color: 000000
userfont1: /.rockbox/fonts/helvR10.fnt
userfont2: /.rockbox/fonts/helvR10.fnt
userfont3: /.rockbox/fonts/helvR12.fnt
userfont4: /.rockbox/fonts/helvR14.fnt
browserfont: /.rockbox/fonts/helvR10.fnt
wpsfont: /.rockbox/fonts/helvR10.fnt
menufont: /.rockbox/fonts/helvR10.fnt

I think I know the problem :)

the following line is missing in lcd-16bit.c in the “normal” lcd_puts_scroll_style_offset function to reset the normal
scrolling line attributes

… s→customline = false;

for completeness I added

s->customline = false;
s->line_font = curfont;
s->line_xpos = 0;
s->line_ypos = 0;

to reset all customline attributes

BTW: I dont use the custom list/menu patch maybe thats
the difference

MrMEC commented on 2006-10-05 02:40

Julius, this patch is great, but I noticed a small glitch with scrolling margins. Granted, I’m stretching the functionality to it’s limits, but still I think this is a bug. Examine the following code:

%e|10|32|146|1|FFFFFF|%al%s%?C <%e|64|32|94|1|FFFFFF|%?ia <%ia|%fn>|%?ia <%ia|%fn» %e|10|50|146|3|FFFFFF|%al%s%?C <%e|64|50|94|3|FFFFFF|%?it <%it|%fm>|%?it <%it|%fm» %e|10|63|146|3|FFFFFF|%al%s%?C <%e|64|63|94|3|FFFFFF|%?id <%id|%d1>|%?id <%id|%d1»

This code allows you to set an alternate display based on whether album art is present, and works fine. However, when aligned right it doesn’t work - nothing is displayed except when a line needs to scroll.

%e|10|32|146|1|FFFFFF|%ar%s%?C <%e|64|32|94|1|FFFFFF|%?ia <%ia|%fn>|%?ia <%ia|%fn» %e|10|50|146|3|FFFFFF|%ar%s%?C <%e|64|50|94|3|FFFFFF|%?it <%it|%fm>|%?it <%it|%fm» %e|10|63|146|3|FFFFFF|%ar%s%?C <%e|64|63|94|3|FFFFFF|%?id <%id|%d1>|%?id <%id|%d1»

However, if the scrolling margin tags are removed everything displays, but then of course there is no scrolling.

%e|10|32|146|1|FFFFFF|%ar%?C <%e|64|32|94|1|FFFFFF|%?ia <%ia|%fn>|%?ia <%ia|%fn» %e|10|50|146|3|FFFFFF|%ar%?C <%e|64|50|94|3|FFFFFF|%?it <%it|%fm>|%?it <%it|%fm» %e|10|63|146|3|FFFFFF|%ar%?C <%e|64|63|94|3|FFFFFF|%?id <%id|%d1>|%?id <%id|%d1»

I’m living with the glitch for now, but if there’s anything you could do to fix it of course I’d be appreciative. Or, if I’m just doing this wrong, I’d appreciate knowing that, too.

The problem is in gwps-common.c
There is only handling of left aligned strings for customline

Adding the following fixes it
if (left_width != 0)

  display->puts_customline_scroll(i,(unsigned char *)data->format_align[i][data->curr_subline[i]].left);

if (center_width != 0)

  display->puts_customline_scroll(i, (unsigned char *)data->format_align[i][data->curr_subline[i]].center);

if (right_width != 0)

  display->puts_customline_scroll(i,(unsigned char *)data->format_align[i][data->curr_subline[i]].right);



intead of only
display→puts_customline_scroll(i,(unsigned char *)data→format_align[i][data→curr_subline[i]].left);
of course :-)

Ok this was of course not the correct solution :-(

I finally used a way similiar to the “normal” scroll lines (below)
Which is to use puts_customline_scroll if scrolling is needed
and putsxy with the correct alignment if no scrolling is needed.

This seems to work as expected


A request to the authos of this patch …

I like the patches that are being implimented into the RB build, but there isn’t much happening for the remote. Can this patch be extended to support the x5 remote?

Any thoughts?



Hi vm3,

I’m pretty sure it can be, it just has to be worked on.
Btw: I had a lot on my head and that’s why there wasn’t much happening here, I will try to sync this soon and than I will have a look on the x5 too.


I would be happy to help making this possible.
I actually change your patch already a little bit to work on the x5
(+ some bugfixes) I will try to upload a version with my changes soon

Unfortunately I dont own a remote and can only use the simulator to test
but we have lots of people using my builds on the iaudophile forums to test :-)


Hi Max,

Thanks a lot for your help, I saw that changing things for e.g. display→set_foreground to lcd_set_foreground fixes a few problems, but I’m just curios, if you do this changes didn’t you get a Warning at compilation? because I do and I think the changes should be made somewhere in the x5 firmware driver files (but it’s just a thought as I said).


I started that way but in the meantime I extended lcd-remote.h
and lcd-remote-2bit.c (which is used for the x5) to include
the new calls from you e.g. lcd_set_custom_width aso.

Now the display→<call> can be used

OOo, that’s great! Thanks a lot Max! could you please upload the new patch when you have it so I can work with that on this weekend?

Thanks again!

I will try but I am a little bit busy at the moment :-( and cannot do what I want to do and that is rockbox
coding :-)

NP, take your time, I know the feeling :)

But the problem with display→set_foreground vs. lcd_set_foreground
is a different one. Since the x5 has only a 2bit remote display.
setting the foreground of the remote makes not much sense.
The result is that nothing is displayed on the remote
Thats the reason for changing it to lcd_set_foreground so that
it only has an effect on the main units screen

I just did a quick and dirty test by using %e tags in an rwps
The only thing missing are the lcd_puts_customline_scroll and
lcd_puts_customline_scroll_style_offset implementations in
lcd-remote-2bit.c but I guess they will look similiar to
the ones in lcd-16bit.c

Attached my changed patches needed for the x5 remote
I added empty functions for lcd_remote_puts_customline_scroll and
lcd_remote_puts_customline_scroll_style_offset at the moment in
lcd-remote-2bit.c otherwise it would crash if using an rwps file
but scrolling is not supported at the moment

Sorry I still use the scroll_margins patch below so the
patches are dependend on it but I guess you know what to do :)

Thanks alot for all the work you have contributed to. Coding is way out of my leage and I’d just like to say thanks for starting the x5 remote implementation



Attached a version of lcd-remote-2bit.c with
lcd_remote_puts_customline_scroll and
(just a copy of your code from lcd-16bit.c adapted to the remote API)
I did a quick test with the simulator and scrolling
seems to work now also on the remote

Eeey eey Max, you’re the best! :) Thanks a lot for the modifications, I will have a look on these on the weekend and and hopefuly make some new patches with all this new additions.

So again, Thanks a lot man!


You know for sure :)
since I also use the scoll_margins patch you must replace
leftmargin and rightmargin with xmargin and your custom_width
in my patches

Just FYI. I uploaded today a x5 build including my remote changes
to customline on the iaudiophile forum. I will keep you informed
of any problems found.

Big Thanks Max! as always!

Unfortunately I wasn’t able to have a look into these modifications/additions, but I really hope/try to do my best to find some free time to get on with the coding.

No problem!


The following in lcd-16bit.c function scroll_thread gives problems when I use an animated peakmeter
Then scrolling lines are not displayed correct


         if (s->customline) {
          	lcd_setmargins(s->line_xpos, s->line_xpos+s->line_width, s->line_ypos);

I found that the last two lines (lcd_setmargins and lcd_set_custom_width)
can be safely removed and that fixes the problem. Still the wps works correct
I am not sure why but maybe you know :-)



Hi all, Due a big request on the misticriver H10 board i dedided to test if i could add these patches to my builds.
So the only patch which makes me crazy is this one. Do i really have to make a seperate build without the scrolling_margins applied??? I read that Max made it to use both scrolling margins and custom line, but as already said… i cant reproduce this… the lcd16bit.c causes always troubles also with the patches he offered. Any hints????

Thanks in advance!

Do you have problems applyinmg the patch or is it not working?

KyleV commented on 2006-10-27 22:33

I can partially answer for Sacha, as i too have had this problem from inception of this line of patches from P.I. Julius, as seen in

I have tried all instructions/modified patches so that the following line of patches applied in there stated order would build for my 5G iPod. They all apply, some requiring you to directly edit the source due to rejects, but when I attempt to build for my iPod, i always get an error. Here is the patches used:-


I apply/build using Cygwin.

It is possible that the patch is not building for all platforms
e.g. I only build for an X5

Can you tell me the eaxct build error you get

The patch has to be edited… some things don’t apply. But the problem is produced by
lcd_puts_custom_line_scroll-style… With your latest patch applied it argues that
something wrong with the variables…

Will reproduce it this morning and post a more precice error message here… As far as i can remember it argued about undeclared or first use of variables fgcolor or so…

Which patch produces the fgcolor and bgcolor variables… i think that ones are missing totally in my buids… I saw this variables occuring also in your patch at the lcd.h hunks…


int right_margin;

   int fgcolor; <--- I dont have those in my lcd.h 
   int bgcolor; <--- where are they from?

+ /* Custome line arguments */
+ bool customline;
+ int line_font;

I applied the patches ind the same order as Kyle mentioned without th lcustom_list_position…

In function: lcd_puts_customline_scroll_style_offset “struct scrollinfo” has no member named fgcolor … has no member bg_color

Any ideas ?

seems that all the different forum build providers meet here :-)

you SHOULD have both lines in lcd.h
They are missing in the patch because they got added by another patch
I use :-(

Just add

int fgcolor;
int bgcolor;

to lcd.h

merging patches is never a good idea :-(

KyleV commented on 2006-10-28 00:48

Okay, tried what you said to put in lcd.h
Applied all the patches i mentioned above except for custom_list_position-20060930.patch.

Tried to build rockbox with Cygwin for my iPod and this is what it spat back out at me :-

CC drivers/lcd-16bit.c
drivers/lcd-16bit.c: In function ‘lcd_puts_customline_scroll_style_offset’:
drivers/lcd-16bit.c:878: warning: implicit declaration of function ‘lcd_getxmarg
in’ drivers/lcd-16bit.c:907: error: ‘xmargin’ undeclared (first use in this function
drivers/lcd-16bit.c:907: error: (Each undeclared identifier is reported only onc
drivers/lcd-16bit.c:907: error: for each function it appears in.)
drivers/lcd-16bit.c: In function ‘scroll_thread’:
drivers/lcd-16bit.c:1036: error: too few arguments to function ‘lcd_setmargins’ make[1]: * [/home/rockbox-src/build/firmware/drivers/lcd-16bit.o] Error 1
* [all] Error 2

You mixed up a patch with scroll_margins and one without
xmargin is replaced with leftmargin when you apply
the scroll_margins patch.
You must use “my” customline-20060930.patch from above
NOT the “original” one
Sorry that it has the same name :-(

I finally found out what causes the problem Max…

Your patch assumes that int fgcolor and int bgcolor; are already set (line 394 and 395 in the patch)
I dunno where these are from but only if i add these two also two my lcd.h (they arent there natively)
the patch runs through without any Errors… Could you figure out which patch adds these two so i can make a clean build???

Thx ;-)


This is my “own” patch of colorized wps:-) I never put it there because it changes some other things too
Sorry for any confusion it caused

But here it is

Thx ;-) I dunno yet what your patch exactly does ;-) but i will figure that out ^^
I’ve got a working build now and must say it was worth the trouble and the H10
users appear to be happy now ;-) THx Max thx to Pijulius (You and PJ are both mentioned
in the build remarks)

FYI: about the problem with animated pictures I wrote above
I finally tracked down this issue. The problem is that you
MUST not mix lines wih and without %e in the same WPS else
it gets screwed up e.g. %t lines etc.

The fix is to always add a “dummy” %e tag in front
e.g. %e|0|0|0|1|FFFFFF|%t0.3% …..

First off, you’ve done some great work on your themes and the WPS support for them, Julius. Thanks!

Second, I tried to use your patches on the current CVS so that I could also include the scrollwheel acceleration patch on my 5G iPod… they were a little out of date, and required a fair amount of massaging to get them to incorporate. I finally did get a build, but it was a bit glitchy, so I reverted back to your 20060930 binary, which works great but doesn’t have the scroll acceleration. (I can get around that with a custom config for the tagcache navigator, though.)

Any news on patch syncs with CVS?

And also, I came across a problem with custom lines and custom fonts in your 20060930 build. Perhaps I’m doing something wrong, or perhaps there’s a problem with the code…

I was customizing your jBlackBox9 theme – I wanted to make the Artist and Title info larger.

So, in the theme .cfg, I added:
userfont2: /.rockbox/fonts/helvR18.fnt

and in the theme .wps, I changed the following lines:
%e|117|5|150|1|FFFFFF|%al%cb d, H:Mc;%e|117|5|240|1|FFFFFF|%alBattery: %bt
%e|133|42|167|1|FFFFFF|%al%s%?ia<%ia|%?d2<%d2|(Artist Unknown)» %e|133|56|167|1|FFFFFF|%al%s%?id<%id|%?d1<%d1|(Album Unknown)» %e|133|70|167|1|FFFFFF|%al%s%?it<%it|%fn>
%e|113|100|187|1|FFFFFF|%alTrack: %pp of %pe - %pc [%pt]
%e|113|114|187|1|FFFFFF|%alCodec: %fc (%fbkbps)
%e|70|154|230|1|FFFFFF|%al%sNext: %?It<%It|%Fn>

%e|117|5|150|1|FFFFFF|%al%cb d, H:Mc;%e|117|5|240|1|FFFFFF|%alBattery: %bt
%e|126|33|190|2|FFFFFF|%al%s%?ia<%ia|%?d2<%d2|(Artist Unknown)» %e|126|56|190|1|999999|%al%s%?id<%id|%?d1<%d1|(Album Unknown)» %e|126|71|190|2|FFFFFF|%al%s%?it<%it|%fn>
%e|113|100|187|1|FFFFFF|%alTrack: %pp of %pe - %pc [%pt]
%e|113|114|187|1|FFFFFF|%alCodec: %fc (%fbkbps)
%e|70|154|230|1|FFFFFF|%al%sNext: %?Ia<%Ia - > %?It<%It|%Fn>

the changes being some x/y modifications to Artist and Title, color modification to Album, and adding the artist to the Next song text.

The mods worked as expected, EXCEPT if the Artist or Song Title is long and scrolls. If this happens, then the Date-Time/Battery text and the Track text get confused about which font they are supposed to be displayed in and keep bouncing between them. So then you end up with the text being correct *most* of the time, but with a weird ghost effect from pieces of the old, larger text still being diplayed below the actual text.

Note that this is only a problem with text that updates itself – the Codec line, the album line, and the Next line all display normally (even with scrolling in the Next line) – and only a problem when the larger text scrolls. If the larger text doesn’t scroll, then the display works perfectly.

Any ideas? Is it a problem with the way I changed things? or a problem with the scrolling mods in the customline patch?

Can you try the patches found here They should apply cleanly on CVS from 1.Nov

About the problem with the font changing.
This comes from the multifont patch I guess
I have also read this on the mystic river forums

I will try to reproduce this on my X5

Thanks Max. I tried your patches (now that I think about it, it was against the Nov. 10 CVS, though), and they were giving me trouble, too. I ended up just tweaking the patches I had to work with the current CVS (and I had some epiphanies about some of the glitches I had seen before).

If you’re interested in comparing my patches to the originals, feel free to check them out: I know C, and can do OK comparing and fixing the failures and fuzz 2’s I found, but I’m still a bit uneasy simply because I’m not the one who wrote the patches, therefore I’m not entirely sure I knew what some of the sections I was tweaking were trying to accomplish. :-) There were a few warnings in the build process which I don’t have time to figure out (see the text files in the /rockbox/ directory for details).

I also posted some builds: These should be direct replacements for Julius’s builds. Except that the USB cable plug/unplug behavior has been reversed – plugging in the cable just charges the iPod, and holding down Menu while plugging it in makes it go into Disk Mode. It’s just easier for me in the long run that way. :-)


Ah, guess I didn’t need the html after all. Sorry ‘bout that.

I also updated my patches :-) The ones at should now apply cleanly agains CVS from 12.Nov
I will compare them to yours

Thanks to Ashen from the misticriver forum there are some bugfixes
in the multitfont customline and scroll_margins patches
If you want to check them out look at
I will post them to their respective flyspray entries after
all the testing is done

I thought Id try to use the patches from to the 20061213 source but an awful lot of hunk errors occurs. So I use the older patch to the source build dated 20061118.

Could you tell me what source those patches on will apply to?

Anyway, 2 problems Ive encountered with the older patches (using ipod nano):

* (This problem relates to the album art patch) It wont display text if put a %s in the “else” condition of album art. Works fine for the “if” part of condition.(%?C<%s scrolls fine|%s no scroll and is just a blank line>).

* Make error comes up, still compiles though. Error is:
drivers/lcd-16bit.c: In function ‘scroll_thread’:
drivers/lcd-16bit.c:1011: warning: ‘fgcolor’ may be used uninitialized in this function
I tried putting int fgcolor; in the lcd.h as mentioned by Sacha (Angyman), but it didnt make any difference.

* Get a briefly weird “popping” happening with text that uses %ac and %ar, and the larger text that pops up is ghosted. Happens on the actual player, doesnt occur in the sim. It seems to correlate with where code is put in the wps.

Are these solved in the newer patches?

They should apply on CVS 20061213 if you apply them in the
order as described in the series file.

Of course some are dependend on each other so it might not
be possible to just use specific ones separately

For now, would it be possible to provide a fix (Im comfortable in editing the code directly, no need to make a patch, just paste code up on here) for the “popping” effect I get on %ac, %ar text? (I noticed it occurs when playing, seems to stop on pause if that helps).

And (I know Im asking alot!) the possibilty to allow %s in the else argument of the album art tag?

Many (many) thanks.

Can you provide a “test” wps showing the problems?
Would make it easier to debug for me

Ok. Have quickly slapped together the files.

Points to note:

* Might have to play around with where the playlist position, clock and date go to get the pop effect.

* “Popping” effect only occurs when playing music and only on the player (i use the nano, dont know if it happens on other players). It doesnt happen on the sim.

* I think the “popping” also happens if the first instance of some text code has a %ac after all the preloads etc used in the wps.

* Cant use %ar or %s in the else condition of the %?C album art. So if no album art is found, a blank line is shown. Only %al works.

If need more info or the source/build, email me or icq (see my profile) as Im online for most of the time. Many thanks.

Thanks I will try it
And for enhancements to the album_art patch you should post this request there :-)

Will do. But be aware that %s, %ac and %ar works for album art patches fine if I dont install the customline, multifont etc patches. Cheers.

Is this also part of your test wps?

%ac and %ar work fine here both with and without album_art
even with your test wps :-)

%e|76|17|90|3|000000|%ac%s%?C<%?ia<%ia|(Artist Unknown)>|>
%e|12|17|154|3|000000|%ac%s%?C<|%?ia<%ia|(Artist Unknown)»

the text is always centered
Or do you mean something different?

Been racking my brains over this!

Decided to try to patch the latest source (19/12/06) with the patches from After some coaxing I got them to patch fine, it didnt build at first, so corrected sum undeclared errors. When running the sim, all text is aligned almost off screen. (See pic below)

And when I try to play music, it crashes. (see pic below)

The patches I use are (applied in that order):


Ive a feeling the scrolling margins and/or the colorised-wps+battery-volume_levels.patch altered the patches that were to be applied after them on the original list. But I couldnt find any thing.

I appreciate any help, getting a massive headache from it all! See to see why Im torturing myself.

If you want to use my customline patch you need to use also the
scroll_margins patch. they depend on each other.
colorized_wps is optional.

BTW: I would like to icq with you but which profile did you meant? :-)

Do a search for me on the rockbox forums, should have my icq thing under my avatar. Cheers.

Updated for current SVN

Ok, I’m trying to build for the H10 with no success. I used the above patch and the two multifont patches! can you post exactly which patches I need to use! A list would be great (with tracker #) sorry for the hassle!

You can take a look here [url][/url]
This is a build containing this patch. You will get also the patches for the actual source there

oops the [url] is not needed here :)

I tried to sync the patch, my first one, so tell me if it is good or not!

Flake commented on 2007-04-02 22:41

the line with scrolling isn’t displayed with center aligning if the text length is less then customline width. With left or right aligning or without scrolling tag is displayed well.
Not displayable example:

Displayable examples:

Flake commented on 2007-04-02 22:46

One more displayable example:

here width is less than text length

I have a version of customline that I think displays this correct
Unfortunately I cannot post it here because it is very dependent on some other patches
I include in my build. But if you want to try take a look at And everyone is welcome to adapt the patch so it works also “standalone” to post it here

Really could use a sync. I can’t figure out how to do it as things are really mixed up now!

Sync please

Please someone sync this patch.

I am working on it
this is not just a simple sync but a rewrite
because of the many changes in the wps code

Thanks a lot Maxwen !

ok first try :)
maybe not the optimal impl but it is a start (synced against 20070430)
depends on multifont multifont-userfonts and scroll_margins patch

you will also need this patch

Works so far as i can see!!!

Sorry I just recognized that the patch is not correct
and depends on another patch I use. I will try to
change this

This version should compile without errors

Anybody else getting weird behavior in the Julius themes with these latest patches? On the Jclix and JBlackGlass themes the progress bar isn’t displaying for me. Since other themes work for me I’m assuming it’s related to customline or another of the jbuild patches.

Sorry for the double post, but I thought I’d add that I experimented a bit and found that if I jumped out of the now playing screen by hitting menu then went back in for a split second the progress bar would show up. I seem to remember a similar problem with the scrolling-margins patch a while back so maybe that information might be helpful to someone. Also I’m pretty much using Max’s stuff so their may be some issues with all of that not being really put together with the iPod in mind, could be wrong though, but it’s a thought. Excellent stuff btw Max, not complaining, just trying to sort this out.

Can you tell me more about your setup?
So you have an iPod? And it happens with jclix and jblackglass theme?
I had also some wps where I needed to move the %pb line in the wps file
to get the progressbar displaying correctly
Can you try to move the %pb at the end of the file?

I’m using
# ymargin_scrollinfo.patch FB6796
# scroll-margins_20070424.patch -p0 FB2954
# album_art_20070426.patch -p0 FB3045
# bmpresize-20070417.patch -p0 FB5697
# progressbar_slider_20070430.patch -p0 FB6505
# multifont-20070515.patch -p0 FB4733
# multifont-userfonts-20070430.patch FB5901
# customline-20070430.patch -p0 FB5900
# colorized-wps-20070430.patch
# custom_list_position-20070430.patch -p0 FB5899
I probably don’t need some of those but I didn’t want to take a chance on dependencies. I have fooled around with the placement of %pb and it doesn’t seem to change anything. I think there may be some sort of problem with it refreshing.

Sorry if I wasted your time Maxwen, but it turned out to not be the patches, but the WPS itself. Adding ypos to the %pb tag fixes this for me.


dependencies as usual

Alright just a quick clarification: To use this i need to also patch scrolling margins, multifont, multifont-userfonts and  FS#6796 ?


Flake commented on 2007-06-29 00:08

This patch is just getting bigger and bigger but why?

I’ve tried patching for the sansa with multifont and scrolling margins and i get a compiling error.

Thats possible since I never tried a build for sansa :)
Can you post the error lines please

Alright, i’ve attached a txt file with the errors in it. I’ve also added the text from when i patched the customline patch. I had a few failed HUNKS. Everything else patched and compiled fine (multifont, userfont, scroll margins, and  FS#6796 ), just had these errors when i got to this patch.

Ok I guess the problem is that dont use the standard scroll margins patch
instead I created my own some time ago which his now out of sync :(
Sorry for the confusion.
I will try to create a version of the customline patch to be used with the
latest “original” one. In the meantime if you like you can try “my version” of scroll_margins found here

err…it’s out of sync? Will i be able to compile with it? guess i’ll find out…

“out of sync” means not in sync with the scroll_margins patch from the tracker
but it should compile fine since I use it in my own builds :)

Ok this one should apply with scroll-margins_20070623 from the tracker

This patch is just getting bigger and bigger but why?
To make it as portable as possible during mainstream RB code changes
some functions are duplicated for customline usage
else syncing the patch is really a “pain” :-)
This patch is just getting bigger and bigger but why?
To make it as portable as possible during mainstream RB code changes
some functions are duplicated for customline usage
else syncing the patch is really a “pain” :-)

Max– two failed HUNKS when patching and a compiling error. Details attached.

are you sure you use source code from 20070622?

Well I’m using the most recent source. But it should work with the most recent as long as the patch is synced right?

But it is not synced with the latest source :-) I dont have the time at the moment

Alright. I tried with the source form 6/22 but some of the other patches didnt work so i’ll just wait for a sync. But i just want to say a big thanks to Max for going around and fixing/syncing patches like a madman!

@maxwen, you probably were unaware of it, but apparently when one uses the Jclix themes those alternating sublines with the RTC date stuff jump font periodically and leave these little text artifacts on the screen when they do. For some time I’ve been playing around with the code trying to fix that but I just can’t figure it out, my last attempt was moving the “nasty hack” that resets the scroller via an empty string to before the area is cleared instead of right after and adding %s to those alternating lines in the wps’s(didn’t help). I’m thinking it may have to do with the change to atomic with the RTC stuff, but I really have no idea. The bad thing is that this bug only shows on the ipod and not the simulator making testing your changes difficult. Any thoughts?

Another quick question to prevent me from doing something really stupid. Basically the only difference between the patches as they are now, and as they were back when Julius was around is that you’ve adapted them for the tokenizer, combined customline and custom_display_width by using s→line_width from the struct scrollinfo and making this for all lcds, not just 16-bit right?

that is correct :)
about the issue with the “jumping” fonts in alternating sublines
I have not seen this till now with the adapted Jclix version for my iAudio
which is basically the same wps code
are you sure the font really changes?
Do you use the scroll_margins patch from the tracker?

As crazy as it sounds the font really does change, it changes right back though leaving a few text artifacts from it’s “jump”. It changes to the font of something that’s scrolling. I use Sufjan Stevens’ scroll intensive albums to test my changes. I’ve tried it with your scrolling-margins, and the one from the tracker using the clean customline, I always have it happen.

Can you try to create a “minimal” wps file where the problem appears and mail it to me?
That would make it much easier for me to reproduce and debug the problem

Sorry it took me so long Max, but that test wps is on it’s way.

i’ve been having a problem using a wps with this. i’ve narrowed it down to either Multifont or Customline and since the two go hand in hand i thought id post it here. My problem is that the current/remaining track time are only updated when you exit the wps and navigate back to it. Also, lines that should scroll are not.

Which wps is doing that Matthew? The customline wps’s I use are JBlackglass, JClix, and cBrownPlastic and I haven’t noticed that behavior in them.

I’m using my Iphone WPS for the sansa. Everything worked at first and then the times stopped refreshing and just a day or two ago i noticed that scrolling had stopped. Would you like me to post the %e lines?

If you want you could email me the entire wps and I’ll take a look at it.

slight revision, adds a switch-case statement to set the font in write_line in gwps-common.c which fixes the problem iPod 30g users were having with the alternating sublines on the JClix themes (just so you guy’s know Max was smart enough to figure that out, not me..:)) Also relocates the block that clears an area before a line is written to before the if statement checking if it’s a custom scrolling line. I believe this will completely get rid of any text-artifacts issues iPod 30g users have.

Hey Travis.

Will the fixes sort out the text problems on the nano? I had problems with stationary text randomly go from normal size to big leaving behind slight pixels of the text onscreen. This had been a problem for about a year. It was always random, sometime it would and sometime it wouldnt. It only happened on the player and not in the sim. Thanks.

I didn’t know nanos did things like that too. I think this should fix that.

Synced. Prerequisites are:

Now the switch case for fonts is just in write_line, also moved the block I moved before that clears the area before a line is written back into the if(customline) part where it belongs.

Oh yeah, thanks for the sync Phil, that kept my simple change simple :-)

Not having the switch case for the fonts in the other place was a very bad idea since a depends on line_width to know whether or not it needs to scroll, and that depends on font_width which depends on that switch case being available before you get to write_line..oops

Anonymous Submitter commented on 2007-09-03 17:58

I think this has an issue with Album art patch, can someone look into it?

I’ve never had any problems with this and the album art patch. Here is a synced to r14560 version of this patch you could try to see if that helps.

Oops, sent the wrong patch up, sorry..

debar commented on 2007-09-08 00:55

I’m getting 3 failed hunks when applying this patch against svn20070831 & svn20070905. I’m also using the following patches, all the latest versions from their respective flyspray pages, applied in the order shown:


The 3 failed hunks are shown in the attached “failed hunks.txt” file. I’ve gone in and tried to manually apply the failed hunks. When I compile (for Gigabeat), everything appears properly with one slight error: when two customlines are shown in the same horizontal line, if one of them scrolls, it clears the entire line. It’s kind of tough to describe in words, so the attached screenshot excerpt “no scrolling.bmp” shows the proper way the WPS should be displayed, which shows properly as long as the line doesn’t scroll. The “scrolling error.bmp” shows the problem when one of the lines scrolls.

The wps code for the 3 lines are so: (Userfont 1 is the smaller font, Userfont 2 is the larger font)
%e|135|120|80|1|A28757|%ar%s%?pn<%pn|Playlist Position>

I should note that this WPS shows properly on EvilG’s custom builds using the same (older version) patches.

Sigh.. looks like I have some more tinkering to do. Your hunk failures are due to me syncing this patch using my updated copy of Max’s scrolling margins patch. To fix your scrolling problem at around line 2005 or so in apps/gui/gwps-common.c in the write_line function move:

/* Clear the area first if there is something to display */

      if (left_width || center_width || right_width) {
          display->fillrect(data->line_xpos, data->line_ypos, data->line_width, string_height);

to around line 2042 immediately after the else section starts right above where it says “/* Nasty hack: we output an empty scrolling string,…“. The reason I moved that is because that fixes a problem the iPods have with some custom lines having leftover text artifacts from what the line said previously. Granted, it was a very nasty hack.. As soon as I’m able I’ll up a new patch that does not have that particular change.

Try this one.

Anonymous Submitter commented on 2007-09-08 13:09

This doesn’t work for me. I tried the latest patch, as well as the previous with that fix.

I get at least 5 HUNK failures, and also compile errors after doing your fix. I just applied y-margin, scroll-margin and multifont.

debar commented on 2007-09-08 13:40

Doing a quick test, the problem is still there. I will try to experiment with it later on when I have time.

What scrolling-margins patch are you guys using, the one from the tracker or Max’s? If you’re using ymargin_scrollinfo you really need to be using Max’s scrolling-margins because the one on the tracker does not account for ymargin being in the scrollinfo struct. Give me a little time and I can up a “clean” version of this patch which will work with scrolling margins from the tracker. Bear in mind if you go that route then you shouldn’t use ymargin_scrollinfo. As far as the problem Thomas is having I will look into that, it looks like data→line_width in that block of code that clears the area for the line doesn’t have the correct value for whatever reason, could be wrong, haven’t properly looked yet. Gimme some days and I will see if I can get this sorted out.

Maybe I’m wrong for posting this here, but this will simplify all of this. For those that have been accustomed to using EvilG’s build here is an updated version of the scroll-margins patch that he used (Max’s version, not the one from the tracker). If you use this one instead of what’s currently on the tracker this should apply cleanly. I’ll still try to get a clean version up as soon as I can, just be patient.

Anonymous Submitter commented on 2007-09-13 15:29

Thanks a lot for your effort. But wouldn’t it be much easier, if y-margin, scrollmargin and this patch would be merged into 1 patch? For most of the WPS you need all 3 anyway.

The problem would be keeping that in sync, that and combining patches that address different things is generally discouraged.

Here’s a clean version of customline that you can use with the scroll-margins that is actually on the tracker. It’s a quick job and I definitely need to tighten it up a bit, but this’ll get you going. Same dependencies as what Phil posted earlier (forget what I said earlier, you do need ymargin_scrollinfo). This basically makes up the difference between the 2 scroll-margins patches as well as being a customline patch. I do believe that is what Phil’s patch did before I put it back to the way it was when I was fulling around with that iPod bug….oops!

Ok, here’s a much better patch. I’ve officially decided to sin no more and not up things with dependencies on alternative versions of patches evolving separately on my computer.

Anonymous Submitter commented on 2007-09-14 12:10

So these are patches are required to apply customline?


@Travis Tooke
Sure a patch shouldn’t addres more than 1 issue. But in this case customline requires those patches, that’s why I think a merged patch would make more sense.

The most recent versions of those patches are required yes. While this does not depend on album art you should apply that before you do this as this patch will place it’s token stuff in the wps-parser based on where the album-art token stuff went. The order I always use is scroll_nostatusbar(you don’t really need this, but if you have an iPod it’s great to have), ymargin_scrollinfo, scroll-margins, album_art, bmpresize, multifont_complete, then customline. That argument has some merit, but it’d still be unusually hard to keep a patch that big in sync. In any case I’m almost certain LLorean would have something to say if I merged all those patches.

synced to latest version of scroll-margins

Anonymous Submitter commented on 2007-09-15 12:16

You didn’t say that we need to apply album art patch in order apply this cleanly!

@Dennis, let me know if with this one you’re still getting that display problem.

debar commented on 2007-09-27 23:53

The display problem I had disappeared with the 9/15 patch that you updated. I will see if all is well still with this new one when I have time this weekend. Thanks.

This should fix the last of the line color issues.

synced for latest version of scroll-margins

final sync for a bit ;) This doesn’t actually fix anything, it’s just a more complete adaptation to the new custom selector settings.

I tried the customline-20070929 patch on rockbox-20070929 build and the remote LCD doesn’t scroll.

I’m not sure if this problem steams from other patches that are required before customline, but can anyone confirm if the latest patches fuction properly on the X5 remote?

For amyone interested, it was the LCD scrolling that wasn’t functioning.

If the latest patch doesn’t work right for the X5 remote then let me know what the bit depth is on that so I can look at the right file and see if I can fix it.

slight cleanup of some things

I tried the latest patch on the 20071005 build and there were a few problems applying the patch. I applies ymargin-scrollinfo_20071002, scroll-margins_20071006-2, album_art_20071005, bmp_resize-20071005, progressbar_slider_20070622, multifont-20071002c, then customline-20071005. I must be doing something wrong. The X5 screen shows the wps properly and scrolls, but the remote lcd doesn’t show anything (I’m sure this is due to me mods to compile). Any possibility to look into this? The bit depth for the remote, I believe is 2bit

btw, what order are you applying the patches and most importantly, which patches (with date)

I think I may be able to fix this for you, assuming your remote lcd uses lcd-remote-2bit-vi.c. I’m going to make some changes and sync this with the latest scroll-margins and put that up for you so you can test it. Bear in mind you will always get one hunk failure with scroll-margins since you’re applying ymargins_scrollinfo and as much as I’d like to I can’t hijack that patch and give it that dependency ;)

Ok, this one is synced with the latest version of scroll-margins, I did a little tinkering in lcd-remote-2bit-vi.c which hopefully is for your particular remote. You’re applying your patches in good order, just use the latest of each one and you should be fine bearing in mind you will get one hunk failing on scroll-margins because of ymargin_scrollinfo, but it should be fairly obvious what is what on manually doing that one, if you have problems though I can send you my version of that which only has the single difference of looking out for where int y_margin is placed in scrollengine.h so that hunk does not fail, everything else is identical. Be sure to get the latest multifont too, I just synced it to add support for the new robotkitten plugin.

oops, do NOT download the above patch, it won’t compile for the X5, sorry about that, shoulda compiled a X5 sim first.

I’ve synced the 20071005 patch, but when a WPS uses a custom line with scrolling, the scrolling line shows the gradient bar selector. (sansa e200, scroll margin 1006-2).

I’ll get this right eventually, I actually fixed that on my custom build, I thought I uploaded my most recent patch that fixed that, I guess I was wrong… Here very shortly I’ll up a patch that fixes that and the remote for the X5 problem.

Ok, I believe this one should fix both of you up.

No, it still shows the gradient bar selector. I wonder if it has something to do with scroll margins, non-custom-line lines that are scroll don’t show the bar though.

It can’t be in scroll-margins, customline has it’s own self-contained setup for scrolling within the margins set by an %e tag. I did forget to add one thing to that last one so I’m going to do that, then thoroughly test that out on my iPod with the most gnarly super scrolling Sufjan Stevens’ songs before I up it. Sorry for the confusion.

Ok, this should [i]really[/i] fix that. I also put that change in the lcd for the remote for the X5 on this one so Bob should get this one as well.

Ok, this one seems to work.

Thank you A LOT for your effort, couldn’t have fixed it on my own (most likely).

Thanks for the update.

I compiled a build using rockbox-20071006-r14998.tar.bz2 and there were a few patch issues (as you had mentioned) but I think I was able to sort that out properly.

Anyways, I got a sim compiled, and when I test it with the wps & rwps I use, the main X5 screen shows the correct wps but the remote doesn’t show anything. When I use a wps that doesn’t use the inputs provided by customline, then the remote and main display function properly. I’m baffled as to what might be cuasing the problem. Would it help if I gave you the patches I’m using (with the mods to overcome errors) and see if there’s something in error within them that I can’t see? I can also provide the wps/rwps that I’m using. Thanks again for the effort, Travis.

Hmm.. yeah, go ahead and send me what patches your using with the mods you used and a wps/rwps so I can test this in the exact environment you’ll be using it in.

Thanks for the update.

I compiled a build using rockbox-20071006-r14998.tar.bz2 and there were a few patch issues (as you had mentioned) but I think I was able to sort that out properly.

Anyways, I got a sim compiled, and when I test it with the wps & rwps I use, the main X5 screen shows the correct wps but the remote doesn’t show anything. When I use a wps that doesn’t use the inputs provided by customline, then the remote and main display function properly. I’m baffled as to what might be cuasing the problem. Would it help if I gave you the patches I’m using (with the mods to overcome errors) and see if there’s something in error within them that I can’t see? I can also provide the wps/rwps that I’m using. Thanks again for the effort, Travis.

Thanks for the update.

I compiled a build using rockbox-20071006-r14998.tar.bz2 and there were a few patch issues (as you had mentioned) but I think I was able to sort that out properly.

Anyways, I got a sim compiled, and when I test it with the wps & rwps I use, the main X5 screen shows the correct wps but the remote doesn’t show anything. When I use a wps that doesn’t use the inputs provided by customline, then the remote and main display function properly. I’m baffled as to what might be cuasing the problem. Would it help if I gave you the patches I’m using (with the mods to overcome errors) and see if there’s something in error within them that I can’t see? I can also provide the wps/rwps that I’m using. Thanks again for the effort, Travis.

I’m working on it, this is proving to be a bit of a challenge though. I can get it to display a non-customline rwps correctly with a customline wps, I just can’t get a customline rwps to work right. @Thomas, in time you’ll probably be surprised what you can fix.

Ok, you could try this one. I could not get this to work on the sim but I suspect it may work on the actual target, at any rate it’s alot closer to what it should be.

@Bob: This one actually works on the sim so you should be fine now!!

Oh yeah, forgot to mention: be sure to get the latest multifont patch with that one.

I can’t seem to patch with the latest release. i did patch with multifont. any ideas?

@Travis, Thanks for the patch update. I compiled a version of RB with this patch and the remote finally displays the rwps. I only have one problem and that is the rwps bitmap images. They appear for a second then disappear. I’m not sure why this is so. I have applied this with the multifont as you mentioned. If you have time, can I e-mail anything to you for troubleshooting? I don’t want to impose, but thank you again for taking the current patch.


@Bob, That’s actually a problem in the rwps itself, in one or two places where you have the code for things like the battery symbol or the volume symbol you have that set up repeatedly in alternating customline sublines. ex: %e|0|0|0|1|FFFFFF|%t0.5 %?bp<%?bc<%xdA|%xdE>|%?bl<%xdA|%xdB|%xdC|%xdD|%xdE»;%e|0|0|0|1|FFFFFF|%t0.5 %?bp<%?bc<%xdB|%xdE>|%?bl<%xdA|%xdB|%xdC|%xdD|%xdE»;%e|0|0|0|1|FFFFFF|%t0.5 %?bp<%?bc<%xdC|%xdE>|%?bl<%xdA|%xdB|%xdC|%xdD|%xdE»;%e|0|0|0|1|FFFFFF|%t0.5 %?bp<%?bc<%xdD|%xdE>|%?bl<%xdA|%xdB|%xdC|%xdD|%xdE»;%e|0|0|0|1|FFFFFF|%t0.5 %?bp<%?bc<%xdE|%xdE>|%?bl<%xdA|%xdB|%xdC|%xdD|%xdE»

when all you needed was: %?bp<%?bc<%xdE|%xdE>|%?bl<%xdA|%xdB|%xdC|%xdD|%xdE»

@Matt, did you also apply ymargin_scrollinfo and scroll-margins? Well, technically for this to patch cleanly you need ymargin_scrollinfo, scroll-margins (which has one hunk which will fail, but it’ll be super easy to manually add that in), album-art, bmpresize, and multifont.

i’m kind of a nub, what do i need to to fix scroll-margins?

you’re right, that was easy to figure out, but patch still wont work:

Hunk #1 succeeded at 1454 (offset 6 lines).
Hunk #2 succeeded at 1818 (offset 6 lines).
Hunk #3 succeeded at 1832 (offset 6 lines).
Hunk #4 succeeded at 1949 (offset 6 lines).
Hunk #5 succeeded at 2036 (offset 6 lines).
Hunk #6 succeeded at 2083 (offset 6 lines).
Hunk #7 succeeded at 2207 (offset 6 lines).
Hunk #8 succeeded at 2257 (offset 6 lines).
patching file apps/gui/gwps.h
patching file apps/gui/wps_parser.c
Hunk #3 FAILED at 832.
Hunk #4 succeeded at 1200 (offset 1 line).
1 out of 4 hunks FAILED – saving rejects to file apps/gui/wps_parser.c.rej
patching file apps/screen_access.c
patching file apps/screen_access.h
patching file firmware/drivers/lcd-16bit.c
patching file firmware/drivers/lcd-2bit-vert.c
patching file firmware/drivers/lcd-remote-1bit-v.c
patching file firmware/drivers/lcd-remote-2bit-vi.c
patching file firmware/export/lcd-remote.h
patching file firmware/export/lcd.h
patching file firmware/export/scroll_engine.h
Hunk #1 succeeded at 51 with fuzz 2.

I’m having issues compliling RockBox with this patch. I get this error, when I try to compile it.

drivers/lcd-16bit.c: In function `lcd_puts_customline_scroll_style_offset’:
drivers/lcd-16bit.c:991: error: structure has no member named `customline’ drivers/lcd-16bit.c:992: error: structure has no member named `line_font’ drivers/lcd-16bit.c:993: error: structure has no member named `line_xpos’ drivers/lcd-16bit.c:994: error: structure has no member named `line_ypos’ drivers/lcd-16bit.c:995: error: structure has no member named `fgcolor’ drivers/lcd-16bit.c:996: error: structure has no member named `line_width’ drivers/lcd-16bit.c:1003: error: structure has no member named `line_width’ drivers/lcd-16bit.c:1016: error: structure has no member named `line_width’ drivers/lcd-16bit.c:1029: error: structure has no member named `line_width’ drivers/lcd-16bit.c:1035: error: structure has no member named `line_xpos’ drivers/lcd-16bit.c:1036: error: structure has no member named `line_xpos’ drivers/lcd-16bit.c:1036: error: structure has no member named `line_width’ drivers/lcd-16bit.c: In function `lcd_puts_scroll_style_offset’:
drivers/lcd-16bit.c:1071: error: structure has no member named `customline’ drivers/lcd-16bit.c:1072: error: structure has no member named `line_font’ drivers/lcd-16bit.c:1073: error: structure has no member named `line_xpos’ drivers/lcd-16bit.c:1074: error: structure has no member named `line_ypos’ drivers/lcd-16bit.c:1075: error: structure has no member named `line_width’ drivers/lcd-16bit.c:1076: error: structure has no member named `fgcolor’ drivers/lcd-16bit.c: In function `lcd_scroll_fn’:
drivers/lcd-16bit.c:1163: error: structure has no member named `customline’ drivers/lcd-16bit.c:1164: error: structure has no member named `line_font’ drivers/lcd-16bit.c:1168: error: structure has no member named `customline’ drivers/lcd-16bit.c:1169: error: structure has no member named `line_xpos’ drivers/lcd-16bit.c:1170: error: structure has no member named `line_ypos’ drivers/lcd-16bit.c:1197: error: structure has no member named `fgcolor’

I’m using the latest patch and latest multifont patch too. Maybe this needs a resync.

@Karl, apply ymargin-scrollinfo, scroll-margins, album_art, bmp_resize, progressbar_slider, multifont, then customline

Hope this helps

Thanks for the reply, but I already applied the patches in that order. I’ve successfully compiled Rockbox a couple of times and this is the first time I’ve faced these errors.

@Karl, apply ymargin-scrollinfo, scroll-margins, album_art, bmp_resize, progressbar_slider, multifont, then customline

Hope this helps

sorry for the multiple posts .. isp connection is messed up and page refreshing re-posts what I had typed before …

This is a slight revision. To fix the bug iPods were having where a line could briefly take on the font face or color of a scrolling line I had iPods set the font and color every single time in write_line. Since this bug only occurred here and there I thought it might be better if I had it check first if the font or color had changed before setting them again (translation: I’m shamelessly copying from Julius’ original code ;-) ). I’m still kinda baffled about how this could happen in the first place since the structs for the various lines are like objects in that they have their own little piece of memory that shouldn’t be “bleeding over” onto one another but oh well.. This will speed the process up, but it won’t really be noticeable so there’s no rush to update to this patch and if you don’t have an iPod you don’t need this update at all.

Thanks for the update, Travis. Rockbox compiled just fine this time around.

Hey, I applied the latest version, and I have a little problem, when using the the VClix themes, which uses custom line heavly.

At the upper left, it shows the clock. The clock changes it’s font periodically (some seconds the normal font, then a split second the other font). Like blinking. I tracked down, that it uses the 4th userfont; when I change it to use the 3rd userfont, the problem isn’t present.

The WPS code looks fine so far (”%e|5|3|68|4|b2bec4|%t7%cl:%cM%cP”). The problem is still there after removing the %t7 which is pretty much senseless.

AFAIK this wasn’t with the last version of the patch.

@Thomas to fix that find where it says “#if defined(IPOD_VIDEO)” in apps/gui/gwps-common.c. Remove that line and also remove the “#endif” just a little bit below that. It should be around line 2135 or so give or take. I thought only iPods had that problem so I wrapped that up that way. What you could do though is instead of removing all that changing that line to “#if defined(IPOD_VIDEO || SANSA_E200)”. That is assuming you have a Sansa e200, I think you do?

Oh! Forgot to mention: also find the same lines in apps/gui/gwps.h and do the same thing. It’ll be around line 397 or so there.

No, that didn’t fix the issue.

Yes, I am using e200.

Hey, I just tried the previous version, and I am getting this issue too.

Weird, either I haven’t notice when I used the 20071011 version in the first place, or something I don’t know yet is causing that.

for now you can use: customline-20071009.patch. It is literally impossible for something to display the wrong userfont on that one because on that one I had it set the font face and color each and every time it wrote to the screen no matter what the target was. I guess my bright idea of having it check first to see if the font or color had changed wasn’t such a good idea. In theory that should’ve worked! :-)…but then in theory this problem shouldn’t even exist. I’ll get a new patch up as soon as I can.

Ok, this one should keep you fixed up without messing up the X5 in the process.

Just tried the patch. On the menu the font colour changes to white, but if I go back to the WPS screen, the font’s back to black.

There are 2 ways you could fix that: You could find all instances of “gui_list→display→set_foreground(global_settings.fg_color);” in apps/gui/list.c and change that to lcd_set_foreground(global_settings.fg_color” and remove the #if defined(IPOD_VIDEO) above it and the #endif below it. You’d have to be sure to do that to all instances of that or you could just remove the line “lcd_set_foreground(data→line_fgcolor); from apps/gui/gwps-common.c. Looks like I’m going to have to make another patch that hopefully REALLY keeps iPods and Sansa’s working without breaking the X5..

Better yet, for now you can just use 20071015. Sometime before the weekend is over I’ll have something up which hopefully will be all things to all people. I’ll probably have a new multifont as well to go with that.

Ok, here you go Bob, this one I do believe finally should be all things to all people. Be sure to get the latest multifont with this one.

Quadruple posting rebel I am…thought I should mention this before I spring it on you. I’m about to take a major departure in one area from the way this patch has been done in the past which I believe should make this work right for everybody without all these hackey if !defined’s I have added. I’m going to take the switch case setting the font out of where all the tokens are getting parsed in gwps-common.c and move that to get_line. Previously I had tried to move that to write_line but ran into the problem of some lines not scrolling properly because it had to know the scrolling width before it got to write_line and that was based partially on the font size. This way we will only have one switch case for that. I’m also going to be bringing back the old line_font_prev and line_color_prev variables to check against in get_line so I only run the switch case when I have to. To avoid potential problems with remotes like in the X5 I’m gonna add a bit-depth check before I go setting foregrounds. In theory all this should work. If it doesn’t just continue to use this previous patch right above me which works for sure, if a bit on the redundant side.

Ok, if I can use you guys as guinea pigs try this one. So far I haven’t encountered any problems with this on my iPod, but I haven’t tested it for long. Be sure to get the latest multifont to go with this.

I still wonder how this patch is gone from 7 kiB in the first version to 53 kiB in the last versions.

Good point.

To be considered, this patch needs to be (a) independent of multifont and (b) as small as possible.

It went from 7 to 53 kib because the initial patch was only for 16bit lcds and there was a helper patch called custom_display_width which is now also contained in this patch. It is not possible to display a custom line that will have a custom font without multifont. If this patch were independent of multifont all you could do would be set a line’s position by pixel and nothing more. At any rate this patch is not going to be committed. Sometime in the future amiconn will be adding something called viewports which will include the functionality included in this patch. I only keep this thing going because the feature is too cool to have to wait for. Oh yeah, don’t get this patch here, I left out a “if(customline)” check that I’m fixing as we speak. This patch here will crash a non-customline wps. Oops…so sorry.

Ok, this one will not do silly things like try and set fonts on a non-customline wps. I’ve been thinking about what you said Steve and I could extricate purely the positional things from this and make a patch of that and then potentially if that were to be committed another added setting the font face and another adding setting the font color. It’s just I’ve been led to believe that viewports is the way it’s going to be and that’s not up to debate. Come to think of it I could resurrect colorized-wps as well. That might serve for the color part of the deal. That one was closed for being out of date but it seemed to be thought of as a good idea by the closer and that patch is still alive and well on my computer here.

Patches are actually meant to do only 1 thing. This might a good time to follow this and split this patch up. This will likely make this patch less dependant on all the other patches as well.

Wouldn’t you know it, it still can change fonts.. Looks like I’m going to go for 20071023-b taking the checking with line_font_prev and whatnot out of it and just having it set the font for every single update. I was hoping it wouldn’t come back to doing it that way. I can split this up, but to get the full functionality people are accustomed to with the %e tag it’s still going to take all of it, it’ll just be in more pieces. I’ll get a working patch up for now. I most likely will start on that but don’t expect anything in a hurry. That is a pretty massive undertaking (dissecting all this) after all.


I’m having this in my mind.
This patch with the %e tag, including x and y parameters. I’d include the font parameter, but in a completely different fashion.
Something like this: A priority which font to use.

if userfonts found
  use them
else-if multifont (aka wpsfont) found
  use them
  use font

In the end, the theme would decide if the multifont patch is required or not.

Ofc I’m unable to code that for now, but this is the idea I have, and this would make the font independant of multifont. I hope you can catch up something of my idea.

The font color would be done in a second patch with another tag, or just included to the userfont-part of multifont (which makes more sense imo).

userfonts is part of multifont. When Max added userfonts to multifont that’s what made this patch possible. Actually the part about if userfonts found use them is pretty much what we’re doing now with the exception of you have to have them (in a customline). The else-if multifont thing, we’re doing that too, that’s the part in gwps-common.c where I have something like if(!customline) set the font to FONT_WPS, even if you’re not using a multifont theme that still works since resetting your theme resets your multifonts and FONT_WPS becomes whatever you have font as if you don’t have a WPS font in that theme.

I meant that in the configfile is something written like: userfont1: /.rockbox/fonts/abc.fnt|#FFFFFF, this makes imo more sense then the current state (this would make different colors possible without this patch).

“with the exception of you have to have them (in a customline).” This is the point I was refering to. This is bugging me a bit. Custom line should be possible without having multifont.

As you might have noticed, my main concern are the wide dependencies between this, multifont, ymargin and scroll margins. This what we need to wipe out imho.

customline could be made to read that but I’d have to include pretty much all of the multifont patch into customline to pull that off. There’s quite a bit of code involved in the multifont patch to make having multiple fonts possible and there’s no way to get around needing that if you want different fonts in any context. But anyways, this patch here *seems* to be working, I forgot to set line_font_prev at all in the previous one. If there are problems with this one just revert back to the one I guaranteed to work.

Wait, colors I can do, but for a userfont I have to have multifont. Not sure exactly what you meant there.

I meant make the multifont patch being responsible for all font rendering (including font color), and custom line only being responsible for bringing multifont’s “output” to the disired coordinates.

I could do that, the downside would be you could only have one color per userfont. To have more than one color for a given font you’d have to make another userfont and that would limit you on the numbers of fonts you could have.

I don’t understand.

Going to the rockbox config file to change the color for the userfont is pretty much the same as going to the wps file and change the color for the userfont (the way it is now).

What I mean is with “userfont1: /.rockbox/fonts/abc.fnt|#FFFFFF” that means userfont1 is always white and if you want to have abc.fnt as any other color you’d have to create another userfont for it.

Ah now I got it. That could be a problem.

But, imho, this is a worthy trade-off, if we can break the dependencies with it.

Well, like I said, I can do color, but for an %e tag to do custom fonts without the multifont patch then customline would have to become substantially bigger.

No, no font color with custom line. Like I said: rendering the font should multifont’s concern (which means, no multifont, no color). Custom line should only arrange the font on the screen. If the user likes font color he should apply multifont.

But imo custom line should also work without multifont at all!

Another solution would be to make a seperate patch for font color.

Ok, this one here will be the final version of this change. This should work perfectly for anyone on any (supported)target. As always if there are problems just revert back to what worked. It will most likely be some time before I am able to look at anything here again, just so you guys know.

synced with latest scroll-margins and album_art. Also is the *real* final version of those changes. I cheated: checked out something from march and applied the last of Julius’ patches to see how he did it.

@Thomas, here’s what I’m likely going to be up to with this in the future: I’m going to be going over the IRC logs to look for where viewports has been discussed and see if I can gather enough information there to get an idea of what it’s supposed to look like. If I can get an adequate understanding of what they have in mind I will post a patch. If I do that I really, really will need all the help I can get so please come over there.

Sure I’m gonna help you if I can. At the moment my C-skills are pretty poor, but it’s getting better every day.

Don’t sell yourself short, I looked over what you did with the customlist patch and that definitely demonstrated an understanding of what is going on.</thread derailment>

synced again

Hi guys,
great job! Can you change this patch, so there would be option to use new tag %e (or another one) only with new color so there will be no need for using coordinates? I would like to use different font colors in WPS, but using coordinates looks very complicated to me.
Thanks a lot ;)

I allready suggested to split this patch, I’d appreciate that.

@mysiak: there is already a patch that does that, it’s colorized-wps. It’s up on my site: ““. Some of those patches are not currently updated but that one is. It uses %Cf for foreground color and %Cb for background color.

@tdtooke: thanks, i’ll ask cpchan if he can add it to his custom build :)
btw. why don’t you submit this patch to this page (if it’s working) so it could be added to SVN?

It wouldn’t be added to SVN for the same reason this patch won’t. Viewports will cover that functionality. And that patch actually was on flyspray in the past, it was rejected. Max picked it up and synced it, in the process it kinda became intermingled with customline. Now that Max is AWOL so to speak I guess I have it and given the circumstances I really don’t feel motivated to make it presentable and put it back on flyspray.

tdooke, when you have made a seperate patch for the coloring, can’t you take these fuction out of custom line?

I did NOT make colorized-wps, I just include it in my build so people that may have created older WPS’s that used this still can. If you want to remove that then go ahead. The only custom/multifont anything that will ever be committed is one that does it by the creation of a window/screen (viewport) that in itself is the positioning and margins and sets fonts because fonts can be defined for each viewport. Nothing I have ever heard in the forums or IRC gives me reason to believe there is any point in further development on this patch because the way it is done has been deemed unacceptable (that’s not just the large scope of it, the very way custom positioning is done would never be accepted because of viewports in the future). That being said I will pull the old ymargin_scrollinfo and scroll-margins dependencies out of this when I have the time, but any other changes I leave for somebody else.

But still, until Viewports are done (which seems to take endlessly), this patch needs to kept sync’d. Especially, but not only with all this dependencies, this gets harder and harder.

I don’t say that we need to further improve this one, but we can bring it into a form which may be easy to port to viewport.

When you want to take out the dependency for scrollmargins, hurry please. Else, I’d say we should take parts of scroll-margin(rightmargin) which apply for the wps, and put it into this one.

I think you might be a bit confused on viewports. There will be no need to port this. The way I understand it is a “viewport” is a window you can define. It’s location on the display will serve as your leftxpos, ypos, etc.. And it will set fonts because those can be defined for individual viewports. At least that’s the way I understood it.. I don’t have time to pull out the dependencies on this right now (maybe next weekend) but at my site in my patches zip file if you use rightmargin there this will patch cleanly until I can update it. It’s at

Hmm,, I use H340 with h100 remote. This path works perfectly on my h340 lcd, but it wasn’t correctly works on my remote.
When I use %e tag with scrolling tag in remote wps, scrolling data printed to h340 lcd. How can I correct this one?


Available keyboard shortcuts


Task Details

Task Editing