--- Log for 04.03.112 Server: hitchcock.freenode.net Channel: #rockbox --- Nick: logbot_ Version: Dancer V4.16 Started: 12 days and 0 hours ago 00.05.26 Quit ashi (Read error: Connection reset by peer) 00.06.11 # would it be possible to have album art as backdrop, a semi-transparent layer over it, and text over that? 00.06.31 # having text in the same viewport as the transparent layer eats through the layer: http://i.imgur.com/JnYuH.png 00.06.49 # having it in a different viewport cuts it off: http://i.imgur.com/Z1IEt.png 00.07.04 # (but scrolling lines don't affect the backdrop album art ;) 00.18.48 Quit ender` (Quit: Stupidity cannot be cured. Stupidity is the only universal capital crime; the sentence is death. There is no appeal, and execution is carried out automatically and without pity. -- Robert A. Heinlein) 00.27.23 # dfkt: in your second example by "cuts it off" do you mean that the new viewport is cutting off the semi-transparent layer? 00.28.01 # yes 00.29.26 # dfkt: how big is the viewport with the text in it? Is it cutting it of or cutting through it (eating through it like the text did in example 1)? 00.31.15 Join wodz [0] (~wodz@89-76-160-35.dynamic.chello.pl) 00.32.47 # OzzieJacks, right, the text viewport wasn't limited... limiting it to 20px height gives this - http://i.imgur.com/wWCct.png 00.33.28 # so i guess it needs 3 layers to achieve thant :/ 00.33.33 # *that 00.33.59 Join curtism [0] (~curtis@unaffiliated/programble) 00.36.27 Quit perrikwp (Ping timeout: 260 seconds) 00.36.51 # actually, i want just the opposite of the last screenshot - shading under the text, none under the free area 00.36.57 # Commit 1c565c9 in rockbox by 03Marcin Bukat: rk27xx: rework linker scripts and crt0.S 00.36.59 # Commit 2f8b44a in rockbox by 03Marcin Bukat: Add RKW firmware file format loader 00.37.00 # Commit f30043a in rockbox by 03Marcin Bukat: rk27xx: add rolo_restart() rk27xx specific variant 00.37.02 # Commit 587f52f in rockbox by 03Marcin Bukat: rk27xx: switch to RKW format for binary 00.37.03 # Commit 7569450 in rockbox by 03Marcin Bukat: rk27load: fix linking with newer toolchains 00.37.04 # Commit ecbda69 in rockbox by 03Marcin Bukat: rename rkw.h header file 00.37.05 DBUG Enqueued KICK CIA-44 00.37.05 # Commit e2d6f92 in rockbox by 03Marcin Bukat: rk27generic: Implement power_off() 00.37.06 # Commit 4718ff9 in rockbox by 03Marcin Bukat: Add RKW support to rolo 00.37.07 *** Alert Mode level 1 00.37.07 # Commit 0263fe3 in rockbox by 03Marcin Bukat: rk27xx: Implement dualboot capable bootloader 00.37.09 # Commit f35e300 in rockbox by 03Marcin Bukat: scramble: add RKW firmware file format encoder 00.38.33 # ehh, I messed up commits order a bit 00.40.06 # ecbda69 build result: All green 00.40.43 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 00.40.43 # * JdGordon was wondering why his laptops fan was going insane :p 00.41.06 # hmm CIA lists commits in wrong order :-) 00.45.07 Quit n1s (Quit: Ex-Chat) 00.47.08 *** Alert Mode OFF 00.48.18 Quit wodz (Quit: Leaving) 00.55.36 # meh 00.55.56 # changing lcd size at runtime isn't as simple as I thought 00.56.32 # get it working for boot time first 00.56.59 # that's easy and working 00.58.01 # and also look at 00.58.07 # http://pastebin.com/eHMwFCeH 00.58.19 # which is zagors uncommited changes to his svn tree for te lcd stuff 00.58.28 # the problem is all the viewports are initialized with the boot time resolution, when it switches the vps are wrong 00.59.02 # iiuc Zagor added a SYS_ notification so things can sort them selves out when that happens 01.00.09 # that's not going to work well 01.00.26 Quit Rower85 (Read error: Connection reset by peer) 01.00.55 # why not? 01.00.59 # a) SYS_* is handled in misc.c and not where the viewports are, b) a callback for every shitty viewport is a waste 01.01.35 # no 01.04.37 # I wonder if it would be possible to fix viewports at lcd_set_viewport()? 01.05.03 Quit DerPapst (Quit: Leaving.) 01.05.25 # only if it is obvioudsly wrong 01.05.45 # I tihnk you are worrying baout a non existant problem 01.06.02 # the skin engine *must* be reinisialised, so that snot an issue 01.06.13 # and just about all other screens reinit all their viewports on entry 01.06.18 # so the SYS_callback is enough 01.06.21 # boot time res might not be sufficient on android. if coming from an activity that shows the statusbar (and we hide it) we get the wrong res from the system (IIRC) 01.09.09 Join Rower85 [0] (husvagn@v-413-alfarv-90.bitnet.nu) 01.13.24 Join passstab [0] (~v@c-68-80-37-73.hsd1.pa.comcast.net) 01.14.45 # JdGordon: depending on how far we go the screen res change could come in at any time (thinking resizing the sdl window), like when a screen that initialises it vp on entering is running 01.17.19 # I don't think we can do that any time soon though :) 01.17.35 # gevaerts, the album art loading line in wavy is %Cl(0,0,100,100,c,c) - i know a "c" centers it - but what's the second "c" for? 01.18.35 # kugel: right, so the current screen needs to handle the SYS_ notification in its event loop and then send it to the default handler to do the reset 01.21.51 # JdGordon: with my current work I don't even get to the main menu. android gets a new res somewhere during the init procedure and then everything just goes horribly wrong 01.22.36 # its broken then :) 01.23.38 # JdGordon: btw I found your lcd_framebuffer pointer has 2 problems. 1) it can't work on android because it doesn't call FBADDR on lcd_update(), the system always draws from lcd_static_framebuffer. 2) it doesn't fixup lcd_backdrop_offset 01.25.33 Quit lebellium (Quit: ChatZilla 0.9.88 [Firefox 11.0/20120228210006]) 01.30.36 Join t0rc [0] (~t0rc@unaffiliated/t0rc/x-5233201) 01.34.39 Join Keripo [0] (~Keripo@eng266.wireless-resnet.upenn.edu) 01.34.45 *** Saving seen data "./dancer.seen" 01.45.04 Join perrikwp [0] (~quassel@cpe-071-076-184-171.triad.res.rr.com) 01.49.41 Quit bertrik (Ping timeout: 260 seconds) 02.04.24 Join perrikwp_ [0] (~quassel@cpe-071-076-184-171.triad.res.rr.com) 02.06.13 Quit dfkt (Quit: -= SysReset 2.55=- Sic gorgiamus allos subjectatos nunc.) 02.06.47 # Is there some convention in rockbox code of whether true or false and zero or non zero should indicate successful completion of a function? 02.06.52 Quit perrikwp (Ping timeout: 260 seconds) 02.08.31 Quit Keripo (Quit: Leaving.) 02.10.13 # OzzieJacks: nup.. unfortunately 02.10.19 # its pretty random for alot of it 02.10.27 # see what the code around what you're playing with does 02.10.32 Join remlap1 [0] (~Patrick@190.28.169.217.in-addr.arpa) 02.10.33 # In some files the conventions go back and forth and even though I can generally figure what is going on from the context it's making my ears bleed. 02.10.35 Quit remlap1 (Client Quit) 02.13.24 Quit remlap (Ping timeout: 255 seconds) 02.17.24 # dkft: vertical 02.20.52 Join perrikwp [0] (~quassel@cpe-071-076-184-171.triad.res.rr.com) 02.23.18 Quit perrikwp_ (Ping timeout: 255 seconds) 02.24.03 # dfkt: I've added this to the wiki now 02.51.01 Join remlap [0] (~Patrick@190.28.169.217.in-addr.arpa) 03.09.48 Join randumbum [0] (~IRCclient@c-71-193-176-198.hsd1.wa.comcast.net) 03.16.24 Join Davide_ [0] (~chatzilla@user-0cev259.cable.mindspring.com) 03.16.44 Nick Davide_ is now known as Davide-NYC (~chatzilla@user-0cev259.cable.mindspring.com) 03.17.22 # I'm selling a pair of RTC modded H120 players. Where is the best place to advertise this in the RB forums? 03.31.19 Quit Davide-NYC (Quit: ChatZilla 0.9.88 [Firefox 10.0.2/20120215223356]) 03.34.46 *** Saving seen data "./dancer.seen" 03.45.23 Quit kadoban (Ping timeout: 260 seconds) 03.55.52 Join antil33t [0] (~Ahurhurr@101.98.150.103) 04.12.21 Join verbtim [0] (~verbtim@212.84.240.14) 04.14.49 Quit amiconn (Disconnected by services) 04.14.49 Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) 04.14.58 Quit pixelma (Disconnected by services) 04.15.00 Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) 04.15.02 Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) 04.15.11 Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) 04.15.38 # is the PLA keymapping a new thing? 04.15.58 # because I see that some of the plugins are getting converted to it 04.22.27 Quit enthdegree (Ping timeout: 252 seconds) 04.24.00 Join dys` [0] (~andreas@krlh-5f71e967.pool.mediaWays.net) 04.24.13 # <[Saint]> verbtim: nup. 04.25.58 Quit dys (Ping timeout: 265 seconds) 04.34.57 # I see now, luginlib_actions.h only defines the common keys all the devices share. 04.35.08 # But why no volume buttons? 04.36.01 # <[Saint]> Patches welcome. 04.37.12 # <[Saint]> In all seriousness, probably because no plugin uses volume keys as control keys. 04.37.31 # <[Saint]> And volume keys never change their function. 04.37.37 Quit [Saint] (Remote host closed the connection) 04.38.12 # Cube on the Clip Zip uses them to change the values of the axes. 04.39.18 # I'm on it though. 04.40.18 # <[Saint_]> It does? Huh...weird. 04.40.38 # <[Saint_]> From what I know of the targets key layout, it shouldn't have to at all. 04.41.23 # up is for pause/start, down changes the layout, left and right is for the axes 04.41.52 # <[Saint_]> doesn't it have a center key? 04.42.12 # it's for highspeed. 04.43.05 # <[Saint_]> Off the top of my head, I can't remember how the iPods (and all similarly layed out DPAD based targets do it), but it _should_ do the same. 04.44.35 Nick [Saint_] is now known as [Saint] (~Saint]@unaffiliated/saint/x-8516940) 04.46.01 # <[Saint]> Oh! 04.46.03 # the iPods use the BUTTON_SCROLL_FWD/BACK, same as the Sansa e200, Fuse 04.46.04 # <[Saint]> Derp! 04.46.17 # <[Saint]> Yeah...I just had a brain fart, sorry. 04.46.24 # <[Saint]> I forgot about scroll being volume. 04.46.36 # Oh! 04.47.11 # * [Saint] needs to up his coffee intake, or lower it, one of the two. 04.48.00 Quit Rower85 (Quit: Hmmm...) 04.48.07 # so I have to add PLA_VOLUP and PLA_VOLDOWN 04.48.52 # <[Saint]> Yeah, wow...I *really* wasn't thinking there. In my little world, targets without dedicated volume buttons don't change the volume, ever :) 04.49.16 # Is there some reason that you can't load a bookmark when there are queued files? 04.54.31 Quit [7] (Disconnected by services) 04.54.55 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 04.59.51 # OzzieJacks: probably because bookmarks havnt been touched in MANY years 05.00.08 Part passstab ("Leaving") 05.00.52 # <[Saint]> That's not entirely true...unless I have a warped sense of time passed. 05.01.12 # <[Saint]> Didn't bookmarking get a makeover /reasobaly/ recent;y? 05.01.23 # <[Saint]> *recently too 05.03.52 # not really 05.04.01 # i did a bit of work probably 3 years ago :p 05.04.29 # <[Saint]> I'm possibly thinking of the bookmark automation. 05.06.50 # Yep 3.5 years ago http://www.rockbox.org/tracker/task/9407?string=bookmark&project=1&type%5B0%5D=4&sev%5B0%5D=&pri%5B0%5D=&due%5B0%5D=&reported%5B0%5D=&cat%5B0%5D=&status%5B0%5D=open&percent%5B0%5D=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto= 05.08.05 # * [Saint] has apparently been around these nerds too long 05.08.08 # <[Saint]> ;) 05.10.27 Join Rob2223 [0] (~Miranda@p4FFD3DF1.dip.t-dialin.net) 05.13.23 # the sansa c100 isn't even in pluginlib_actions.c 05.14.01 Quit Rob2222 (Ping timeout: 244 seconds) 05.21.47 # What program is recommended to make/edit the 32 bit icon files. Adobe Fireworks wouldn't allow loading of those icon files. gimp? 05.23.41 Quit nosa-j (Read error: Connection reset by peer) 05.24.56 Join nosa-j [0] (~m00k@adsl-74-235-42-18.clt.bellsouth.net) 05.27.01 # <[Saint]> OzzieJacks: What files are you talking about, exactly? 05.27.15 # <[Saint]> Please list the filename as it appears to you. 05.27.23 Quit advcomp2019 (Read error: Connection reset by peer) 05.27.36 # The files in the rockbox Icon directory 05.28.22 # <[Saint]> They're just bitmaps. 05.29.28 # But they are 32 bit bitmaps with transparency and that seems to give some programs problems. Most normal bitmaps are just 24 bit. 05.31.37 # <[Saint]> GIMP, IrfanView, etc. 05.31.48 # <[Saint]> "Image editors that don't suck", basically. 05.32.48 # yea 05.32.51 # <[Saint]> You can also just use any old bitmap you want. 05.33.01 # <[Saint]> Transparency isn't a necessity. 05.33.42 # <[Saint]> You can also use FF00FF as "transparency" in a "normal" bitmap. 05.33.45 # The wiki also needs updating since it states that the icon files are 16-bit and color <255,0,255> is transparent but doesn't mention being able to use files with actual transparency. 05.34.01 # <[Saint]> Well...it's a wiki. 05.34.47 *** Saving seen data "./dancer.seen" 05.35.43 Quit anewuser () 05.35.56 # <[Saint]> Register, amd I'll be happy to add you to the WikiUsersGroup 05.36.09 # <[Saint]> *and, too 05.36.31 # I trying to make a theme that uses android ICS style and I am trying to use as many standard android icons as I can. They come as png's with transparency so I guess what I really need is a program to convert png's to 32 bit bmp without losing the transparency. 05.37.21 # <[Saint]> Convert .png to .bmp, then specify a colour to use as the alpha when exporting, done. 05.37.23 # Sorry I am new to all this. Register where? 05.37.37 # Ok thanks. 05.38.17 # Ok I see now. 05.40.54 Join Keripo [0] (~Keripo@eng338.wireless-resnet.upenn.edu) 05.49.53 # Registered for wiki my login is OsborneJacobs 05.50.58 # <[Saint]> Ok, one second. I'll just whip Chrome into submission and add you. 05.51.00 Quit guymann (Quit: Lost terminal) 05.52.14 # <[Saint]> That looks relatively "normal", so I'm going to assume that's your real name? (some people seem to miss that part, or deliberately avoid it). 05.52.33 # yep real name 05.56.08 Join guymann [0] (~charles@64-252-120-35.adsl.snet.net) 05.57.53 # <[Saint]> OzzieJacks: OsborneJacobs added to WikiUsersGroup 05.59.05 # <[Saint]> As a side note to others...is there any harm in clearing the registered users that never created pages (and therefore never logged in, ever) from WikiUsersGroup? 05.59.20 # <[Saint]> I can see there's a large handful of such users. 06.00.48 # <[Saint]> If they do indeed want edit rights, asking them to re-apply isn't too much of a big deal is it? 06.02.58 # <[Saint]> A rough count gives me 42 users given edit rights that never actually completed the registration by actually signing in. 06.03.44 # <[Saint]> I'd also *really* love to run "sort" on the usersgroup...but, I'm a little apprehensive of breaking the wiki for a few hundred users :) 06.04.03 # the /apps/keymaps/keymap-logikdax.c file says "Button Code Definition for Sandisk c200 target" 06.04.14 # I guess it was copied verbatim 06.06.16 # * [Saint] doesn't /really/ see how running sort on the usersgroup could "break_stuff" as long as the correct CSV magic is intact, but will wait for approval from the wiki God(s). 06.07.35 Join [Saint_] [0] (~Saint]@101.98.158.103) 06.07.35 Quit [Saint_] (Changing host) 06.07.35 Join [Saint_] [0] (~Saint]@unaffiliated/saint/x-8516940) 06.10.40 Quit [Saint] (Ping timeout: 255 seconds) 06.13.22 Quit t0rc (Quit: WeeChat 0.3.7) 06.14.59 # verbtim: yeah a lot of stuff is blindly copied then modified until it works 06.16.08 # config/*.h is the worst i think: wrong comments, incorrect defines 06.17.46 # * [Saint_] heartily agrees that is a nightmare 06.18.16 # especially for sansa ams, we ought to have a config-ams.h common file 06.18.23 # <[Saint_]> Its really hard when you don't have that much of an understanding what a particular section is doing, then assume that the comments and defines are in fact truthful. 06.23.08 # <[Saint_]> gevaerts: scorche: other_forum_peeps: ...would it be possible to remove the artificial limit of "Recent Posts"? 06.23.37 # which artificial limit? 06.23.45 # <[Saint_]> Its my preferred way to view the forums, but depending on activity 10 pages really doesn't cover that much of a backlog unless I checkit daily. 06.23.59 # <[Saint_]> *check it 06.24.54 # i just check a few subforums 06.25.04 # <[Saint_]> Perhaps there's some setting for this that I'm missing somewhere, but I only seem to get 10 pages of 8~10 posts, which often isn't really that far back in time at all. 06.25.24 # yeah the limit's always been there afaik 06.25.25 # <[Saint_]> I mean, I know its "Recent Posts" and all...but, yeah. 06.25.37 Quit Galois (Ping timeout: 260 seconds) 06.25.37 # yeah, probably - but that is more of a code thing 06.26.29 # i try to make as little code changes as possible.. 06.26.40 # <[Saint_]> Yeah, that's cool. Its not worth digging for, just wondering if it was something you could just define easily. 06.26.52 # no, there sint an easy option for that 06.27.16 # <[Saint_]> Fair enough, consider me answered :) 06.27.24 # it should be a trivial code change if you really want, but like i said, i try to make as little code changes as possible to make updating easier 06.29.01 # funman: well, for the keymaps there is the apps/keymaps/keymap-newtarget.c 06.36.15 # <[Saint_]> I saw a nice forum the other day that listed their recent posts from page 1 to and hovered an approximate date over the page number when you mouseover'd it. 06.36.21 # <[Saint_]> Made me jealous :) 07.05.05 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 07.13.08 Quit OzzieJacks (Ping timeout: 248 seconds) 07.22.05 Nick [Saint_] is now known as [Saint] (~Saint]@unaffiliated/saint/x-8516940) 07.34.50 *** Saving seen data "./dancer.seen" 07.37.52 Quit Kiwi_Cam (Quit: Leaving) 07.40.57 Join KiwiCam [0] (~KiwiCAM@22.197.69.111.dynamic.snap.net.nz) 07.41.32 # Added volume buttons in apps/plugins/lib/pluginlib_actions.c, found some problems too http://gerrit.rockbox.org/172 07.43.59 Quit guymann (Quit: Lost terminal) 07.44.57 Quit qnm (Ping timeout: 260 seconds) 07.47.35 Join qnm [0] (~qnm@2001:44b8:3110:f300:208:9bff:fec0:179a) 08.24.24 Join Galois [0] (djao@efnet-math.org) 08.36.05 Quit verbtim (Quit: Leaving) 08.37.07 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019) 08.48.00 Quit curtism (Quit: Live Long and Prosper) 09.12.29 Join captainkwel [0] (captainkew@207-237-110-248.c3-0.nyr-ubr2.nyr.ny.cable.rcn.com) 09.15.51 Quit CaptainKewl (Ping timeout: 246 seconds) 09.34.54 *** Saving seen data "./dancer.seen" 09.37.15 Join ender` [0] (~ender@foo.eternallybored.org) 09.48.37 Quit captainkwel (Ping timeout: 260 seconds) 09.49.56 Quit kadoban (Ping timeout: 248 seconds) 09.58.50 Join mystica555_ [0] (~Mike@71-211-204-107.hlrn.qwest.net) 10.01.20 Join petur [0] (~petur@rockbox/developer/petur) 10.12.15 Join n1s [0] (~n1s@nl118-175-223.student.uu.se) 10.12.15 Quit n1s (Changing host) 10.12.15 Join n1s [0] (~n1s@rockbox/developer/n1s) 10.20.48 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 10.22.25 Join TomColler [0] (~thomas@net-93-144-183-165.cust.dsl.teletu.it) 10.29.41 Join mortalis [0] (~mortalis@77.108.98.176) 10.31.26 Quit n1s (Read error: Connection timed out) 10.37.24 # Torne: is gerrit in www? 10.41.00 # Commit 975332d in rockbox by 03Dominik Riebeling: Disable built-in make rules for binutils 2.16.1. 10.43.48 # 975332d build result: All green 10.43.54 Join n1s [0] (~n1s@nl118-175-223.student.uu.se) 10.43.54 Quit n1s (Changing host) 10.43.54 Join n1s [0] (~n1s@rockbox/developer/n1s) 10.45.17 # so if i want to sync someone else's patch from gerrit and push it, how do i do that? 10.46.02 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 10.46.02 Quit bertrik (Changing host) 10.46.02 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 10.50.19 # n1s: I don't know if we have established a policy for that but normally the uploader should deal with it (IIUC) 10.50.59 # we switched to gerrit, a code-review-only system, to not make the impression to authors that we are responsible for their patches 10.51.43 # err... no we didnt 10.51.55 # we switched because it is in every way better than FS 10.52.03 # JdGordon: sorry, but we did 10.52.04 # except this way 10.52.16 # I was part of the discussion at the devcon 10.53.02 # code-review-only? 10.53.13 # so any changeset uploaded for review that can not be trivially applied by git will be auto abandoned? 10.54.05 # n1s: no 10.54.55 # no? 10.55.46 # a change that doesnt apply anymore is not automatically abandoned 10.56.17 # but we're not supposed to sync it even if we want to? 10.56.27 # of course you can 10.56.39 # suggesting otherwise is moronic 10.56.42 # i know i *can* 10.56.47 # you *might* have to push to a new ticket 10.57.00 # but it being on gerrit doesnt mean we cant touch it if we want to 10.57.03 # i'm just trying to figure out wth i'm supposed to do 10.57.20 # n1s: the idea is that this is the job of the original author 10.57.21 # do whatever you want :) 10.57.43 # I don't know what happens if you push to the same ticket, it'll probably work 10.58.02 # * [Saint] doesn't see gerrit as being any better than FS for the "dump it and run" style authors. 10.58.24 # in this case it's easier to just revert one other change for now 10.58.39 # next question is how the author syncs his clone with your changes 10.58.58 # How do we collaborate with git in a more sensible forkish way untill the branch is ready to merge? 10.59.14 # git commit -a --amend is not very good for that 11.00.05 # JdGordon: pull from each other, perhaps through some external repo (at github or so) 11.00.15 Quit Keripo (Read error: Connection reset by peer) 11.00.38 # [Saint]: in this case gerrit will auto-abandon after a timeout 11.02.32 # gevaerts: i think i'll revert 0cc6ba0 for now and kill that file later 11.02.34 # <[Saint]> Which is what I liked about flyspray...a 2 year old patch not suitable for commit can still prove a useful starting point for someone else. 11.02.43 # we have auto-abandon on reviews? Since when? 11.03.10 # [Saint]: this is exactly the bit rot we do not want anymore 11.03.26 # [Saint]: it will still hang around in the repository. 11.03.47 # <[Saint]> kugel: No...what you guys didn't want was the air of responsibility. 11.03.54 # <[Saint]> them being there did no harm. 11.04.26 # [Saint]: the problem is that it gets too much data to keep any kind of overview 11.04.57 # (and people not wanting to feel responsible, but that's both for contributors and committers) 11.05.09 # it does harm in that there are so many of them that nobody wants to have a look at them 11.05.27 # <[Saint]> search by date. done. 11.05.30 # the same will happen with gerrit 11.05.37 # <[Saint]> yep. 11.05.50 # searching in FS is rather limited, like you can't search by target IIRC 11.06.11 # the main difference is that gerrit encourages contributors to work on their patches while FS didn't 11.08.04 # <[Saint]> I'm having a hard time trying to think of how...but, ok. 11.08.22 Join DerPapst [0] (~Adium@91-64-115-27-dynip.superkabel.de) 11.08.56 # <[Saint]> New patches are relatively easy to miss in FS, but in time that will happen with gerrit too I imagine. 11.09.05 # I think we have already by now committed a lot more external contributions than ever with FS in the same time 11.09.32 # <[Saint]> I put that down to "new toy" syndrome. 11.10.33 # n1s: I don't suppose you want to wait for wtachi(?) to sync his work? 11.10.38 # well, the barrier to push a change from gerrit is much lower but i don't think it will help much with people just dumping changes in and leaving them there 11.11.45 # * bluebrother agrees with n1s 11.11.53 # I expect you can update it for him (and I won't complain if you do) but wtachi will probably get problems to incooperate your update in his local tree 11.12.19 # i got the impression he did the dump to be rid of it 11.12.21 # [Saint]: one of the nice things is that gerrit makes it much easier to actually do a review. No need to download a diff and apply it first -- then changes are in git so you can use gitweb to browse them 11.12.38 Join lebellium [0] (~chatzilla@g225186094.adsl.alicedsl.de) 11.12.50 # <[Saint]> bluebrother: thats the only real benefit I see so far. 11.13.10 # JdGordon: if that's true we should even more wait for him to update, to see if he's going to work further on it 11.13.11 # you want to comment on a specific part of a change? Add a comment in the review. No need to write stuff like "I don't like the change made to file foo.c in line x" 11.13.17 # kugel: sure i can ask him to do that, i wasn't planning of taking that route btw, as the only problem is that the standalone makefile was deleted by gevaerts yesterday i was just going to revert that and apply the two changesets that touch it before removing it 11.13.23 # <[Saint]> I just need to convince myself that its worth the loss of the archive of potentially useful non-applied patches on FS 11.13.34 # you want to merge a review? Just press a button. No need to download a diff, apply it, and thing of a commit message for yourself 11.13.46 # [Saint]: the archive is still there. 11.14.16 Join MethoS- [0] (~clemens@134.102.106.250) 11.14.22 # <[Saint]> bluebrother: But, it won't increase. Rejected patches are rejected now, poof, gone. 11.14.45 # <[Saint]> though amusingly you can still upload patches to FS ;) 11.14.52 # n1s: moving all the codecs is really invasive. we should wait to see if JdGordon is right before doing it, shouldn't we? 11.14.54 # <[Saint]> maybe we should stop that? 11.15.16 # kugel: is right about what? 11.15.36 # "< JdGordon> i got the impression he did the dump to be rid of it"" 11.15.49 # i.e. that he dumped his gsoc work to be done with it and never come back 11.16.49 # maybe, i don't see why that matters though? 11.16.51 # <[Saint]> How does one determine correctness here? 11.16.59 # [Saint]: wait forever 11.17.06 # <[Saint]> Ahhh ;) 11.17.13 # <[Saint]> Yes, silly me. 11.17.41 # n1s: do we want this in if he isnt going to maintain it at all? who will do it? 11.17.48 # [Saint]: git ls-remote git://git.rockbox.org/rockbox.git refs/changes/* 11.17.52 # yes, we do 11.18.07 # if this modularization is something we want i don't think it matters if the original author is no longer around 11.18.35 # <[Saint]> bluebrother: thanks for that. 11.18.57 # there's also the "abandoned" link in gerrit 11.19.11 # kugel: how does the maintenance of the codecs change when they are moved to a different dir with mainly some difference to build system and api? 11.19.14 # and I think you can filter the reason it was abandoned 11.19.24 # it's the same as with people contributing a single patch: if we want the feature someone needs to maintain it. We can't expect the original author to maintain his code forever. 11.20.07 # otherwise "committers" would need to do everything. 11.20.23 # these patches are mainly moving files and improving the separation of the codecs and dsp from the rest of the core 11.20.25 # and if the patch contributed is actually a larger patch series ... well, what's the difference? 11.20.37 # it's not really a thing to maintain imo 11.21.05 # okay then 11.21.18 # <[Saint]> n1s: I just aught myself wondering how much "maintaining" this would actually need also. 11.21.30 # <[Saint]> presumably its a "commit and it works" thing. 11.21.40 # <[Saint]> *caught myself 11.21.52 # I just fear the librbcodec thing is going to rod like e.g. the theme editor 11.22.09 # and if we have tests there will be even less maintainance work since there's an easy way to proof it's not broken. 11.22.32 # kugel: it is in use by all our builds 11.23.01 # <[Saint]> the theme editor got neglected because the builds needn't care if it functions or not. 11.23.13 # <[Saint]> if this breaks, we'll know about it, and want to fix it. 11.23.30 # yeps. If the theme editor had been part of the commit builds it would have been fixed long ago 11.23.31 # and with gevaerts' changes the warble tool can be added to the automated builds 11.24.19 # [Saint], bluebrother: I don't mean "it compiles" only. many new tags aren't handled by the theme editor too 11.24.54 # <[Saint]> because they were added after the theme editor fell badly out of sync. 11.26.22 # the Theme Editor is broken because of (a) buflib, (b) new tags, (c) nobody caring (and noticing?) 11.26.46 # <[Saint]> I understand the concern you have, and it would apply to pretty much anything else...but not here, people will notice /pretty/ quickly if playback breaks. 11.26.50 # if it would be only new tags it should simply ignore them. But right now it doesn't compile at all 11.27.21 # <[Saint]> bluebrother: I believe you're correct. It happily ignores tags it doesn't understand iirc 11.27.48 # [Saint]: at least IIRC it's been designed in a way to do that. 11.27.53 # bluebrother: and d) beiber dissapearing and it being c++ and i tinhk only me with an interest in having it work (though i wont touch it as it is) 11.28.23 # <[Saint]> as cool as it is, "themers" seem to like coding by hand. 11.28.40 # i tihnk because there really isnt anything better 11.28.44 # <[Saint]> it'd be great for newcomers, but I imagine they'd switch to "by hand" eventually too. 11.28.47 # the editor could have fixed that but alas 11.29.00 # [Saint]: isn't that what the Theme Editor is for? At least it's some kind of editor with some auto-preview :) 11.29.17 # JdGordon: any list of things that need to get adjusted to make it work again? 11.29.39 # <[Saint]> It was never quite 100%, and the C++ bit scares me right of :) 11.29.42 # I'd really want to have it working but right now I'm having trouble to find time for maintaining Rockbox Utility ... 11.29.44 # <[Saint]> *off 11.29.58 # C++ isn't that much of a problem ... 11.30.10 # at least once you get a bit used to the OOP approach. 11.30.13 # bluebrother: honestly I never liked the apporach and i think if someone wanted to fix it they should only use the UI and rebuild the tag handlers from scratch 11.30.36 # (which is something you can use in C as well -- though the language doesn't have OOP functionality built-in) 11.30.57 # JdGordon: we had the other appraoch too. it equally rotted 11.31.05 # at the very least it should be using a factory pattern and a single Tag class 11.31.18 # kugel: ? 11.31.42 # if you mean do everything with rockbox up to drawing to framebuffer 11.32.43 # anyway, I fully expect LUA to make the entire skinning engine irrelevant in the coming year 11.32.53 # the entire UI should be lua driven :) 11.33.16 # I don't think that'll happen any time soon :) 11.34.25 # Commit f8de21f in rockbox by 03Andrew Ryabinin: rkw-loader: Fix wrong include 11.34.43 # * bluebrother remembers saying something like dropping the skinning stuff in favour of lua some time ago :) 11.34.56 *** Saving seen data "./dancer.seen" 11.36.48 # JdGordon: btw, any reason why the skin parser isn't generated with something like yacc / bison? 11.37.15 Join [Saint_] [0] (~Saint]@unaffiliated/saint/x-8516940) 11.37.25 # f8de21f build result: All green 11.41.31 # bluebrother: its not a regular language? 11.41.39 # and what would that give us? 11.41.46 # the parser is bloody marvelous! 11.41.58 Quit factor (Ping timeout: 260 seconds) 11.42.04 # ah right, forgot about that last thing :P 11.42.51 # well, i mean, the parser library has completly lied up to expectations. doing it in bison/yacc would be a waste 11.43.12 # all the work goes into the upper layers (the stuff in apps/) 11.43.20 # lived* 11.47.03 Join factor [0] (~factor@r74-195-184-248.msk1cmtc01.mskgok.ok.dh.suddenlink.net) 11.50.35 # possible. I've just been wondering :) 11.52.33 Quit petur (Quit: here today, gone tomorrow) 12.10.50 Join [Saint__] [0] (~Saint]@unaffiliated/saint/x-8516940) 12.13.49 Quit [Saint_] (Ping timeout: 265 seconds) 12.24.13 # Commit f6e17e8 in rockbox by 03Bertrik Sikken: AMSv2: add proper definitions for charge current 12.26.43 # f6e17e8 build result: All green 12.44.34 Join anewuser [0] (~anewuser@190.207.129.184) 12.44.34 Quit anewuser (Changing host) 12.44.34 Join anewuser [0] (~anewuser@unaffiliated/anewuser) 12.49.11 # Hello JdGordon, gevaerts, [Saint] and the other, I simplified the most possible my SBS to find where is the issue but still can't find it http://pastie.org/3517851 does someone understand why the menu viewport disappears when it skips to the next track? 13.01.45 Quit [Saint] (Read error: Connection reset by peer) 13.03.49 # I also tried with a single viewport (not conditional) and the same occurs 13.08.28 # <[Saint__]> There's an issue with conditional ui vieqports that means you used to need a beeline between %Vi calls...is this not the case anymore? 13.08.53 # <[Saint__]> Damn autocomplete. 13.09.10 # <[Saint__]> There's an issue with conditional ui vieqports that means you used to need a *newline* between %Vi calls...is this not the case anymore? 13.10.45 # what issue? 13.11.17 # <[Saint__]> "It didn't work" :) 13.12.08 # <[Saint__]> Conditional ui viewports needed a newline between the %Vi calls, and I never recall this being (deliberately) fixed. 13.12.24 # is it on flyspray? 13.13.34 # "Someone" should also report blank line issue 13.13.46 # the problem is probably simple test cases 13.13.50 # <[Saint__]> Nope, its in the "don't put it on flyspray, I'll remember it and get around to it eventually (but you might need to remind me)" bank of knowledge that is Mr. Gordon. 13.14.22 # * kugel wonders why he says something like said 13.14.43 # a missed report is much worse than a superfluous one 13.15.01 # <[Saint__]> Its usually when I "discover" something he already knows/knew about. 13.15.33 # <[Saint__]> This seems to have either been fixed and I missed it, or it fixed itself, though. 13.15.43 # I'm sorry but I don't really understand "newline between %Vi calls". What should I modify concretely to get it working (if ever possible)? 13.16.38 # <[Saint__]> Well....%Vi calls used to require a newline to separate them. That might be a good start. 13.17.31 # <[Saint__]> Your code is a little backwards, but, it _should_ work fine still. 13.18.28 # you mean a blank or commented line between %Vi(X..) and %Vi(Z...)? 13.18.37 # <[Saint__]> Blank. 13.19.27 # <[Saint__]> I suspect that's not actually the problem here if it works at all though. 13.19.41 # indeed that doesn't seem to fix the issue 13.20.51 # <[Saint__]> It just caught my interest as that used to be the only way to get conditional ui viewports working. And I don't recall it being deliberately fixed (though it may well have been). 13.22.22 # well I also have these conditional UI viewports on my clip zip theme and it works fine but it doesn't include the new layering (no %VB tag) 13.26.04 # <[Saint__]> Your code looks benign enough for me to suspect this is an internal error, not one you're creating. 13.26.31 # <[Saint__]> Post the example sbs and a description on flyspray. 13.27.12 # <[Saint__]> (Then poke Jd with the FS# in here after doing so) 13.28.04 # hah, backtrace in panicf, very useful 13.28.29 # <[Saint__]> The only issues I see with your sbs are purely cosmetic, and even then, its mostly personal preference. 13.31.12 Quit fyre^OS (Read error: Connection reset by peer) 13.31.30 Join fyrestorm [0] (~nnscript@cpe-68-173-235-85.nyc.res.rr.com) 13.32.07 # well drawing the menu viewport fullscreen when the mini-player is OFF was indeed a personal obsession, just cosmetic and I'm happy to get that done with your help yesterday But I guess the menu viewport disappearing is not a matter of personal preference, it's an annoying bug for anyone. I'll try to report it on flyspray as you say. Never did that so I *try* 13.34.43 # <[Saint__]> Oh, I didn't mean the sbs (as in visually), but rather the layout of the sbs code itself. 13.34.59 *** Saving seen data "./dancer.seen" 13.35.13 # <[Saint__]> I have some (probably very personal) slightly different conventions. 13.37.38 # ah the code itself... I hate mine too, it doesn't look nice and clean at all. It's a pain for me to read my own code ahaha 13.39.15 # <[Saint__]> I'm a fan of the theme, for what its worth. A while ago I went to a ridiculous degree of effort to recreate the Apple iPod OF for a few different targets. 13.39.24 # <[Saint__]> So, I feel your pain. :) 13.40.11 # What "reported version" shoud I select in the bug report? 13.41.26 # <[Saint__]> Add the version ID in the description if its not a release build (which it isn't). 13.43.01 # <[Saint__]> It should allow you to select "current build", then make sure you state the vetoing ID in the description. 13.43.18 # <[Saint__]> *version ID 13.43.36 # <[Saint__]> (Man, I really hate touchscreen keyboards) 13.55.03 # JdGordon: when you have time, could you have a look at that http://www.rockbox.org/tracker/task/12606 ? :) 13.57.49 Join y4n [0] (y4n@unaffiliated/y4ndexx) 13.58.25 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 14.01.32 Join Rower85 [0] (husvagn@v-413-alfarv-90.bitnet.nu) 14.11.19 # lebellium: probably not for at least a week 14.11.34 Quit DerPapst (Quit: Leaving.) 14.12.01 # ok no problem, I'll remind you next week :) 14.14.24 # [Saint__]: also im pretty sure i never said to not put it on FS 14.15.11 # lebellium: haha ok, i probalby know what the issue is there.. umm 14.15.32 # its not because of %VB 14.15.44 # it might be because of gevaerts's recent commit though 14.16.42 # lebellium: do "git revert b9bf6cd" and see if thar fixes it please 14.18.14 # how am I supposed to do a "git revert b9bf6cd" ? sorry for the dummy questions but I'm not a RB expert at all^^ 14.18.30 # in your rockbox source directory 14.18.35 # you're doing your own builds right? 14.18.41 # not at all 14.18.50 # I'm downloading the existing builds 14.18.52 # ah, lame :( 14.19.15 # sorry :( 14.19.24 # bug me next weekend then, I wont have mcuh/any time this week 14.19.50 # maybe someone nice here could compile this git revert version for me? 14.24.02 Join rarog [0] (~chatzilla@p4FF5C824.dip.t-dialin.net) 14.24.31 # actually, yeah, I doubt that change is the issue 14.24.34 # its probably an ancient bug 14.24.44 # * JdGordon just likes trying to pass the buck 14.25.11 # lol 14.25.55 # what is really needed is for someone with the inclination to copyy the stock cabbie themes list and make it a sbs with as few lines as possible 14.26.17 # then we can actuallly use the skin lists as *the* list drawer and makesure it works 100% 14.26.31 # then when it does, we can remove th einbuilt list drawing code and clean things up alot 14.28.39 # pamaury: is the sdparm-output of any relevance for rb usb configuration, that I uploaded into FS#12458? 14.28.40 # http://www.rockbox.org/tracker/task/12458 3[Fuze+] The SD card is not reported in usb mode (bugs, new) 14.30.05 # rarog: I don't know, might be. I don't know UMS very well, gevaerts knows that better than me I think 14.30.08 Join dfkt [0] (dfkt@unaffiliated/dfkt) 14.31.26 # At least this is some part of configuration/information that OF provides while rb just ignores... 14.39.15 # And I sill wonder, how to read information from dmesg"(Mode Sense: 0b 00 00 08" from RB vs. OF "Mode Sense: 3e 00 00 00". I can't find proper source of information, I think that this is jus another collection of flags. 14.40.34 # ums is scsi based, the spec is really huge, there are bits everywhere unfortunately 14.43.01 # doh, I hoped for some proper documentation of a standard... 14.43.31 # but perhaps it's only given out to people paying license fees 14.45.25 # oh I think you can download the specs for free (or at least the draft specs), but you have to know exactly which specs to combine 14.46.05 # and to know which parts of the specs are actually used by the host OS 14.47.23 # a hard and fine bit of work to do then. :/ 14.48.26 # we should have documented the source documents already 14.51.02 # rarog: basically that's usb + usb mass storage + scsi, you need at least scsi SPC (primary commands) and probably block commands (SBC) or reduced bloc k(RBC) 14.54.45 # sound like some voodoo to me. :D 14.55.04 # yeah I know, give me a minute to find links to them 14.58.40 Join harrydehengst [0] (537515fa@gateway/web/freenode/ip.83.117.21.250) 14.59.22 Join verbtim [0] (~verbtim@212.84.240.243) 15.00.31 # hm, need to load backdrops that don't match the screen size 15.04.18 Join nexea [0] (~nexea@115.251.38.145) 15.06.31 # hello all...i am Gaurav, an Undergraduate from IIT Delhi, India, interested in participating in GSOC12... 15.08.13 # nexea: hello 15.09.32 # kugel: hello...whr can i find more abt the ongoing projects and skillsets required in rockbox?? i am new to open source 15.10.04 Quit verbtim (Quit: Leaving) 15.10.11 # nexea: we have an ideas page, http://www.rockbox.org/wiki/SummerOfCode2012. you can get an idea of the required skills there 15.10.45 # however, the ideas are not fixed and we also welcome ideas that students have 15.13.17 # nexea: generally skills at either digital signal processing or operating system levels are nice to have 15.13.38 # kugel: thanks a lot :) is this the channel to discuss specific ideas and projects or do they have different channels? 15.13.52 # this channel works 15.14.41 # kugel: i am doing my majors in Electrical engineering and have done courses like Digital Signal Processing, Image Processing, Embedded Systems etc...i guess that wud help rite? 15.15.06 # yes definitely 15.17.24 # * [Saint__] isn't fond of the idea of drawing very basic lists with the skinned list theme magic 15.17.32 # <[Saint__]> There's no call for it. 15.17.50 # <[Saint__]> Too much code to do something *very* simple. 15.18.25 # <[Saint__]> If cabbie did anything fancy, I might agree...but, it doesn't, nor should it (IMO). 15.18.49 # the idea is to make it work so that the legacy list code can be removed 15.19.02 # not to make basic lists more fancy 15.19.22 # <[Saint__]> And break ~99% of all themes? 15.19.50 # why break them? 15.20.01 # I would assume a fallback sbs would be provided 15.20.31 # much like the current classic statusbar is drawn using skin code now 15.20.51 # <[Saint__]> Well...iiuc, removing the in-core list drawing would break any theme that used its own sbs but didn't use skinned lists. 15.21.04 # <[Saint__]> Which is a LOT. 15.21.17 # but hardly 99% 15.21.30 # but I think compatiblity for those can be provided as well 15.21.45 # Hi, rockbox on my sandisk clip zip crashes when I put in my 16GB microSDHC card... any ideas? 15.21.47 # <[Saint__]> And in all honesty, skinned lists are a bloody nightmare. 15.22.24 # I'm surprised you say this :) 15.22.59 # <[Saint__]> "Providing compatibility" for themes not using skinned lists == leaving in-core list drawing in place. 15.23.08 # <[Saint__]> So, its kinda pointless. 15.23.12 # no 15.23.43 # rarog: mass storage class: http://www.usb.org/developers/devclass_docs/ 15.23.44 # <[Saint__]> I'm not sure how it could be some otherwise without breakage. 15.23.55 # <[Saint__]> *be done 15.24.06 # should be simple. you can detect if a theme uses the skin list tags 15.24.17 # It says "*PANIC* Stkov dircache bt pc: 0x3005950 A: 0x3005956 bt end" 15.24.35 # if not act as if it would by calling default tags 15.24.57 # <[Saint__]> kugel: and what draws the lists if it doesn't? Or, what...refuse to render the sbs and draw some default? 15.25.13 # the skin code 15.25.37 # the skin code can easily draw the list even if the sbs does not specify skin list tags 15.25.59 # just needs to be implemented 15.26.13 # <[Saint__]> Isn't that what's being proposed to be removed? Or am I misunderstanding. 15.26.15 # but first of all the skin lists need to work properly, without regressions 15.26.41 # no, currently the normal list code (not skin code) draws the normal lists 15.27.07 # apps/gui/list.c, as opposed to apps/gui/skin_engine/*.c 15.27.28 # rarog: this might be of interest: http://www.lvr.com/mass_storage_faq.htm 15.27.38 # <[Saint__]> I took "remove the inbuilt list code" to mean "skinned lists and only skinned lists will render lists from this point" 15.27.43 # pamaury: Thx. 15.27.52 # <[Saint__]> Otherwise, what would be drawing the lists? 15.27.58 # rarog: they try "Reduced Block Commands" on google, there are several drafts, you want version 2 at least 15.28.06 # yes, that doesnt necessarily mean the skin has to provide skin list tags 15.28.56 # rarog: as for primary commands, try "primary commands spc-2" 15.29.28 # <[Saint__]> kugel: but I'm not sure what would be drawing the lists if it didn't. 15.29.37 # <[Saint__]> I'm confused. 15.30.30 # the skin code 15.30.31 Join kevku [0] (~kevku@2001:470:28:773::) 15.30.52 # we could sort of hard code skin list tags for the case the skin doesn't provide them 15.31.38 # rarog: do any other rockbox usb devices work for you? 15.32.03 # [Saint__]: see how http://git.rockbox.org/?p=rockbox.git;a=blob;f=apps/gui/statusbar-skinned.c;h=fc9735da21d0fe69e4e2f9144e4d551a8e6afd00;hb=HEAD#l203 has the classic statusbar embedded 15.32.11 # <[Saint__]> Are the inbuilt lists *really* that bad that this is needed? Or is this just change for the sake of change? 15.32.29 # [Saint__]: maintaining two separate bits of code? 15.32.45 # gevaerts: what do you mean? if you mean hardware, I have only fuze+, if you mean drives, they all work (with linux) 15.32.53 # <[Saint__]> To be really honest, to me, skinned lists are a novelty and little more. 15.33.30 # <[Saint__]> Too much of a nightmare for me to bother with. Its a lot of effort to do something really simple. 15.33.51 # <[Saint__]> Its really cool if you want a fancy sbs, but a but needless otherwise. 15.33.53 # nothing is going to happen until the skin list work properly, with the same feature set as normal lists 15.34.12 # <[Saint__]> Right...so I wont hold me breath ;) 15.34.16 # once that's done you shouldn't notice the transition 15.34.35 # it would be all internally 15.34.49 # rarog: also, did you try with a different PID? 15.34.57 Quit nexea (Quit: nexea) 15.35.02 # [Saint__]: nobody is working on it currently yes 15.35.04 *** Saving seen data "./dancer.seen" 15.35.45 # not even JdGordon who was heavily advocating them 15.37.14 # gevaerts: didn't try different PID, as my OF reset its settings and was trying MTP mode, after I reset it to MSC I didn't have the difference between RB and OF. 15.37.40 # <[Saint__]> I think the reason for that might be because its only really useful for rather extreme themes. Gevaerts style themes :) 15.38.09 # in msc mode OF of fuze+ doesn't report PID. 15.38.13 # <[Saint__]> To draw just a simple list, its a lot of code to do something the core can make "just work". 15.38.42 # <[Saint__]> But...if you want to skew your lusts across the screen...it's awesome! 15.38.49 # <[Saint__]> *lists 15.38.50 # <[Saint__]> Lol 15.39.34 # rarog: (a) a USB device *always* has a PID, and (b) the reason I asked you to try it was to make sure the problem isn't tied to the OF PID being treated differently somehow 15.41.34 # <[Saint__]> Another reason it didn't "take off" is the other useful thing skinned lists can do was negated by your list height patch, kugel. 15.42.02 # <[Saint__]> That's speculation of course, but it means skinned lists are useful only for very extreme cases. 15.42.36 # [Saint__]: the reason they didn't take of was that they've bascially been broken until earlier this week 15.43.12 # <[Saint__]> gevaerts: I'm not so sure about that...it took this long for someone to notice how broken they were. 15.43.15 # the item height itself was also the only thing that works (when I tried), skin lists are completely broken on touchscreen 15.43.47 # [Saint__]: well, they were more broken than they used to be since the buflib change, but they didn't work well at all before that 15.43.56 # gevaerts: Ah, you mean idProduct, RB uses the same as OF does. Only bcdDevice differs (0.01 in RB and 1.00 in OF) and with iSerial (0 in RB and 5 in OF) 15.44.08 # rarog: I KNOW IT USES THE SAME 15.44.26 # I'M ASKING IF IT BEHAVES DIFFERNTLY IF IT DOESN'T USE THE SAME 15.45.11 # I'm sorry and confused. :/ I can retest it with different PID in windows. 15.49.17 # n1s: by the way, the warble build can't just be added to the build system, it *has* been added to the build system 15.49.40 # lebellium: your theme doesn't use skinned lists, right? 15.49.55 Join stoffel [0] (~quassel@pD9E432B4.dip.t-dialin.net) 15.50.29 # gevaerts: nope 15.51.13 # Right. Then that change to %Lb handling *can't* be related to the bug you're seeing 15.54.10 # That is what JdGordon supposed? Because I personnaly did not blame your commits for being the cause :p 15.54.33 # Yes, that one 15.55.02 # I know it wasn't your suggestion :) 16.00.51 # gevaerts: i don't see it in the build table 16.01.34 # It's there. "SDL Application - warble" 16.01.55 # It's cut of at "war" though 16.02.19 # ah yes, that's nice i missed that bit 16.02.39 # did you drop the -DDEBUG or fix the warnings? 16.03.29 # The warnings were caused by too much hackery in the __PCTOOL__ vs. SIMULATOR situation 16.03.44 # That's what I spent most of my time on last night 16.04.07 # Actually moving warble to the regular build system was minor in comparison 16.04.55 # oh, i only saw that they were for printf style formatting but i guess one of those defines implies some debug mode or other 16.05.47 # that's a mess i don't like either, the DEBUGF vs logf vs the various custom *debug macros/functions that just get redefined into each other in a big tangle 16.06.05 # Oh, right, that one. Not sure... 16.07.15 # the classical size_t and %d 16.08.41 # i have no idea if our debug printing things support %z or whatever and also i'm not sure if things should have them on by default 16.08.47 # hm, it seems I did drop DEBUG 16.13.12 Join TheLemonMan [0] (~LemonBoy@ppp-105-35.26-151.libero.it) 16.30.52 # n1s: yes it does 16.30.59 # (support %z) 16.31.05 # iirc 16.32.47 # kugel: logf or DEBUGF or both? 16.33.20 # Commit cd8e11b in rockbox by 03Michael Sevakis: Tweak some PCM drivers for less typecasting with the data pointer. 16.33.25 Quit stoffel (Ping timeout: 244 seconds) 16.33.56 # n1s: both 16.34.09 # that's nice, we should use that then 16.34.31 # i think many places do already 16.35.47 # Commit 534117d in rockbox by 03Frank Gevaerts: Re-add -DDEBUG to the warble makefile 16.36.01 # cd8e11b build result: All green 16.38.44 # 534117d build result: All green 16.39.11 Quit ender| (Quit: Odhajam) 16.39.48 Join ender| [0] (~ender1@foo.eternallybored.org) 16.40.27 # rockbox crashes on my sandisk clip zip when I put in my 16GB microSDHC card :( 16.41.46 # does anyone know if I can do anything about this? 16.43.16 # what was a negative height in %Vl again? 16.43.31 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 16.43.56 Join echizen [0] (537515fa@gateway/web/freenode/ip.83.117.21.250) 16.44.56 Quit echizen (Client Quit) 16.46.24 # The x and y values may be negative which means "pixels from the far edge".. i.e x == -50 means 50 pixels from the right edge 16.46.27 # The width and height values may also be negative which means almost the same as above... 16.46.30 # haha 16.46.58 # * kugel can't make a sense of it 16.50.32 # <[Saint__]> Its insanity. 16.50.51 # <[Saint__]> I avoid specifying negative values wherever possible. 16.51.53 Join shanttu [0] (~shanttu@dsl-hkibrasgw3-ffdec300-4.dhcp.inet.fi) 16.53.12 # going to need it when I want to support multiple resolutions with one skin 16.54.45 # I guess negative width means whatever width from x to LCD_WIDTH+n (where n is the negative width) 17.06.45 # kugel: I can't parse your last statement 17.09.24 # hmm, I'm not sure why but I thought only the x and y *position* could be negative, not the width 17.09.52 # or height 17.14.39 # gevaerts: No change for me, Internal is shoed to be recognized, but no second drive with other pid. 17.17.39 # kugel: I guess for negative width it means that your defined x-position in the declaration is effectively the right edge (where it is the left usually). I'm not sure if that's what you said earlier... 17.23.58 Join evilnick [0] (~evilnick@rockbox/staff/evilnick) 17.26.11 Quit kadoban (Ping timeout: 260 seconds) 17.31.24 Quit evilnick (Read error: Connection reset by peer) 17.35.06 *** Saving seen data "./dancer.seen" 17.36.07 Join Horscht [0] (~Horscht@p57B57BD6.dip.t-dialin.net) 17.36.07 Quit Horscht (Changing host) 17.36.07 Join Horscht [0] (~Horscht@xbmc/user/horscht) 17.38.31 # *shown 18.00.40 Quit [Saint__] (Remote host closed the connection) 18.02.28 Quit Horscht (Quit: Verlassend) 18.05.08 Join Martus [0] (~chatzilla@aaap244.neoplus.adsl.tpnet.pl) 18.10.39 Join evilnick [0] (~evilnick@rockbox/staff/evilnick) 18.12.38 Quit harrydehengst (Quit: Page closed) 18.15.24 Quit TheLemonMan (Quit: WeeChat 0.3.7) 18.18.48 Join prof_wolfff [0] (~user1@82.159.9.243.dyn.user.ono.com) 18.21.41 Quit prof_wolfff (Client Quit) 18.29.51 Join Topy [0] (Topy44@f048204134.adsl.alicedsl.de) 18.32.28 Join CaptainKewl [0] (captainkew@207-237-110-248.c3-0.nyr-ubr2.nyr.ny.cable.rcn.com) 18.33.08 Quit T44 (Ping timeout: 276 seconds) 18.36.42 Quit perrikwp (Ping timeout: 272 seconds) 18.39.17 Join perrikwp [0] (~quassel@cpe-071-076-184-171.triad.res.rr.com) 18.43.14 Join enthdegree [0] (~BitchX@unaffiliated/enthdegree) 18.43.37 Quit perrikwp (Ping timeout: 240 seconds) 18.44.58 Join perrikwp [0] (~quassel@cpe-071-076-184-171.triad.res.rr.com) 18.45.20 Join guymann [0] (~charles@64-252-120-35.adsl.snet.net) 18.47.04 Join amy_56 [0] (4caf22a1@gateway/web/freenode/ip.76.175.34.161) 18.49.21 # Hi, I tried playing a .mpg file on my Sansa and it basically shut off. It displayed no video, played no audio and I had to press the power button for forever to get it to /really/ turn off. Is it just not fast enough to play video? 18.49.45 # that depends on the video file 18.50.15 # If the video is the correct dimensions/bitrate/codec for your sansa, then it should play fine 18.50.30 # first, it needs to be mpeg2 with mp3 audio. Second, you can't expect it to be powerful enough to scale the video. That means that you need to transcode your video. 18.50.35 # unless you already did that of course 18.51.32 # ...I might have just fed it through mencoder... 18.52.35 Quit amy_56 (Quit: Page closed) 18.52.40 # hmm, the manual doesn't state anything about transcoding video. 18.57.07 Join curtism [0] (~curtis@unaffiliated/programble) 18.59.50 Join lebellium_ [0] (~chatzilla@f052242058.adsl.alicedsl.de) 19.00.40 Join DannyA [0] (~DannyAtta@host86-161-94-54.range86-161.btcentralplus.com) 19.01.56 # Hi there. I have set up my server to be a Rockbox build client. It worked for a while, but I now get "Your build client has been temporarily blocked by the administrators due to: build client fails on simulators." 19.02.23 Quit lebellium (Ping timeout: 276 seconds) 19.02.30 # But I have built the simulator manually with no problems 19.02.31 Nick lebellium_ is now known as lebellium (~chatzilla@f052242058.adsl.alicedsl.de) 19.02.47 # Anyone know what I should do? 19.03.59 # DannyA: let me check 19.04.38 # OK thanks 19.04.50 # hm, I vaguely remember this... 19.06.37 # DannyA: unfortunately we don't have build logs anymore. I'll reenable it now and then we'll see what happens 19.07.18 # Commit 769e817 in www by 03Frank Gevaerts: Re-enable rigaud-dannya 19.07.55 # Thanks again. Would I expect to see any errors reported in rbclient.log ? 19.08.15 # hmm, having mingw-cross-env for cross compiling sims (and some time Rockbox Utility) could be useful, couldn't it? 19.08.28 # I don't think so 19.10.24 # DannyA: the problem is that build errors as such are normal. It's when specific build errors only happen on one client that something's wrong 19.11.01 # Good point. 19.11.12 # If it happens again I'll make sure to save a build log 19.11.47 Join DerPapst [0] (~Adium@91-64-115-27-dynip.superkabel.de) 19.11.59 # I'm running a standard Debian 6 64bit server, and as I understand it the simulator doesn't use a cross-compiler 19.12.24 # So if there is something wrong it ought to be easy to fix 19.12.43 # * gevaerts nods 19.24.52 Quit mortalis (Quit: KVIrc 4.1.1 Equilibrium http://www.kvirc.net/) 19.26.56 Quit enthdegree (Ping timeout: 260 seconds) 19.35.09 *** Saving seen data "./dancer.seen" 19.38.48 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 19.43.55 Join Thra11 [0] (~thrall@31.185.37.4) 20.03.21 # seems in current revisions rockbox takes a long time to shut down sometimes, while other times it's as fast as always... noticed on x5 and clip+/clipzip 20.03.41 # also in the simulators 20.04.22 Part TomColler 20.10.04 Quit DannyA (Quit: Leaving) 20.15.36 Quit Martus (Quit: ChatZilla 0.9.88 [Firefox 10.0.2/20120215223356]) 20.18.04 Join verbtim [0] (~verbtim@212.84.240.243) 20.21.55 # I'm going to abandon this change http://gerrit.rockbox.org/172 Should I at least push the updated comments for the two keymaps? 20.45.49 Join mortalis [0] (~mortalis@77.108.98.176) 20.51.06 # Commit d18a5ca in rockbox by 03Michael Sevakis: Tweak paramters of mp3_play_data and callback. 20.54.31 # d18a5ca build result: All green 20.55.33 Quit curtism (Quit: Live Long and Prosper) 20.58.47 Quit verbtim (Quit: Leaving) 21.01.27 Join curtism [0] (~curtis@bas11-montreal02-1128531121.dsl.bell.ca) 21.01.28 Quit curtism (Changing host) 21.01.28 Join curtism [0] (~curtis@unaffiliated/programble) 21.09.39 Join dartmouth [0] (~dartmouth@74-44-33-160.dr01.lmrs.ia.frontiernet.net) 21.12.25 # I have a crummy but serviceable background replacement for rockblox on the clip zip, here's a screendump on-device - would this be worth adding until someone sorts out the size/placement of everything else? http://img594.imageshack.us/img594/4475/dump120304140918.png 21.23.41 Quit y4n (Quit: HOLY SHIT! WE'RE ALL JUST LIVING ON A GINORMOUS FUCKING SPINNING ROCK FLOATING THROUGH SPACE CIRCLING A BIG FUCKING BALL OF FIRE!!!) 21.26.47 Join mshathlonxp [0] (msh@84.237.141.70) 21.28.52 # pamaury, from looking at the stfm1000 so far, it seems some stuff is done in software (which is unfortunate), like doing the soft-mute and stereo blend adjust (based on received signal strength). 21.29.37 Join Thra11_ [0] (~thrall@87.112.193.18) 21.29.47 # also there seems to be some complicated stuff to avoid the tuner locking on to spurious frequencies, like harmonics from some DC-DC converter 21.30.25 # I think I'll start reverse engineering a datasheet first :) 21.32.03 Quit Thra11 (Ping timeout: 244 seconds) 21.35.10 *** Saving seen data "./dancer.seen" 21.45.26 Quit kevku (Ping timeout: 272 seconds) 21.49.55 # wtf? Rockbox Utility doesn't get spoken by NVDA on W7 64bit :( 21.50.20 # hmm, seems to be related to Rockbox Utility running elevated but the NVDA not. Running NVDA as admin makes that work 21.50.30 # that's kinda broken :( 21.51.53 Quit randumbum (Quit: ChatZilla 0.9.88 [Firefox 10.0.2/20120216101208]) 21.52.48 Quit benedikt93 (Quit: Bye ;)) 21.53.23 # That seems *really* broken to me 21.56.51 # bertrik: and RDS ! 21.57.18 # bertrik: the RDS code of the driver looks awful, like doing software integration 21.57.34 Join randumbum [0] (~IRCclient@c-71-193-176-198.hsd1.wa.comcast.net) 21.59.19 Quit mortalis (Quit: KVIrc 4.1.1 Equilibrium http://www.kvirc.net/) 22.02.04 # pamaury, I didn't notice that yet 22.02.25 # bertrik: I seems to remember that the linux driver has a 1000+ line file just for that 22.04.53 # oh, true, looks like a nightmare 22.05.01 # In any case I think the stfm1000 will be quite challenging 22.05.31 Join Strife89 [0] (~Strife89@207-144-19-39.cstel.net) 22.06.09 # that's pretty stupid, I don't think the hardware they save is worthwhile given how much you need to do in software 22.10.10 # rasher, bluebrother: the header in fonts/15-Adobe-Helvetica.bdf is rather clear I'd say 22.10.46 # bertrik: so the deal seems acceptable that I send you my xfi2 if I get it to work (sufficiently) 22.11.07 # ? 22.11.09 # gevaerts: that too... 22.11.42 # pamaury, ok. If/when I get stuck or bored, I'll send it back to you, OK? 22.11.45 # * gevaerts considers replying that no part of rockbox is less non-free than those fonts 22.14.28 Quit bluebrother (Disconnected by services) 22.14.29 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) 22.17.44 # Is locking option only for playing screen and turned off on every other screen on all RB targets or is this only Fuze+ specific? 22.18.41 Quit fs-bluebot (Ping timeout: 276 seconds) 22.20.03 Join fs-bluebot [0] (~fs-bluebo@g224237197.adsl.alicedsl.de) 22.24.17 Topic "We're now in a feature freeze for 3.11 | Please read before speaking: http://www.rockbox.org/wiki/IrcGuidelines | Please direct offtopic/social chat to #rockbox-community | This channel is logged at http://www.rockbox.org/irc" by ChanServ (ChanServ@services.) 22.24.36 Quit Strife89 (Ping timeout: 248 seconds) 22.24.37 Quit shanttu (Quit: Leaving) 22.24.45 # n1s: can we wait for a week with further rbcodec commits? 22.26.11 # is it possible to get another version of adobe helvetica? 22.26.22 # like 24 or 25 pixel 22.28.00 Join Strife89 [0] (~Strife89@207.144.201.128) 22.29.48 # what do we do with nano2g USB for 3.11 ? 22.31.13 # Llorean: lambdacalculus379: would one of you lend me your nano2g ? 22.34.17 Join jlbiasini [0] (~metaphys@d86-32-96-55.cust.tele2.at) 22.35.08 # rarog: I didn't managed to have it working on all screen so I supposed it was only in WPS 22.36.06 Join OzzieJacks [0] (~OzzieJack@24-246-47-198.cable.teksavvy.com) 22.36.16 Quit Strife89 (Ping timeout: 245 seconds) 22.37.22 Quit n1s (Ping timeout: 272 seconds) 22.37.37 Join Strife89 [0] (~Strife89@207-144-19-39.cstel.net) 22.38.47 # kugel: if one (let say me) set those variable for key name in PLA couldn't we reuse theme directly in the manual. Setting automaticly the \PluginsX variable? 22.39.06 # *those directly 22.40.10 # jlbiasini, rarog: that's true for the software lock (so all targets that don't have a hold switch) 22.42.31 # kugel: look for a file called helvR24.bdf on the net 22.44.53 # nice, %x seems broken 22.45.54 # pixelma: is it for some reason or just because no one implement it otherwise? 22.46.21 # pamaury, basic tuning on the stfm1000 looks doable 22.46.32 # funman: Unfortunately, I don't know where mine is right now. I'm in the process of moving now. 22.46.45 # it seems to have an i2s output, I wonder if it also has analog out (that would probably be easier to setup) 22.47.00 # When would you need it by? 22.47.12 # Llorean: before 3.11 release :) 22.47.26 # i'll ask lambda on fb 22.50.11 # gevaerts: thanks 22.56.51 Join saratoga [0] (98032909@gateway/web/freenode/ip.152.3.41.9) 23.00.44 # kugel: how is %x broken? 23.00.51 # I modified its behaviour and made it very clear 23.02.39 Join LambdaCalculus37 [0] (~rmenes@c-68-32-226-242.hsd1.nj.comcast.net) 23.02.40 Quit LambdaCalculus37 (Changing host) 23.02.40 Join LambdaCalculus37 [0] (~rmenes@rockbox/staff/LambdaCalculus37) 23.03.17 # jlbiasini: it's been this way forever ( the first targets are softhold targets) and I think it's been chosen on purpose in the sense of 'you put the player only away once you chose the music to listen too and you want quick access to the file browser again if playlist has ended' 23.04.21 # ok 23.05.16 # I myself am so used to it, I'd quite annoyed if someone changed that in the menu or file browser - in the radio screen it could be also useful but then my softhold target (an OndioFM) is short of buttons 23.05.33 # FWIW I don't think it has to stay that way on all targets if they have enough buttons 23.05.41 Quit Strife89 (Ping timeout: 260 seconds) 23.05.49 # on touch screen devices in particular that might not be the best way to do things 23.06.18 Join hillshum [0] (~hillshum@71-219-57-106.slkc.qwest.net) 23.07.11 Quit DerPapst (Quit: Leaving.) 23.07.15 # hmm, maybe. It's also more likely to touch something accidentally than pressing a button accidentall 23.07.21 # y 23.08.05 # I'm also wondering if the fact that touch devices have to different kind of button (solid and virtual) could be raised as an argument to have volume working while in hold mode 23.08.38 # in general i don't see a problem with revisiting old design choices on new devices so long as its implemented sanely and in a way that doesn't hurt users of older devices 23.08.41 # for touch device we could even remap solid button to have some pocket mode 23.08.57 # that's a bit of a weird view of a hold mode... 23.09.09 # right 23.09.19 # but if there were two, maybe 23.09.35 # the fuze+ is a weird device in general right? not a true touchscreen but some kind of gesture based one? 23.09.51 # i haven't used one in person yet 23.10.24 # for the moment we have a 3x3 grid on the touch part 23.10.39 # + 2 volume solid button 23.10.46 # + solid power 23.11.06 # so a screen and a separate touch pad? 23.11.30 # JdGordon: meh, I see it now 23.11.42 # while hold is on we could have *optionnaly* volume key and short power for play/pause for example this would awesome 23.12.00 # pixelma: yes 23.12.09 # that's it 23.12.35 # do I need an extra viewport 0,0,-,- just for it? 23.12.49 # no 23.13.08 # you do need to put it in *a* viepwort though 23.13.52 # * kugel wonders if that theme breakage was really needed 23.14.11 # different behaviour of %x? So how is cabbiev2 doing then on monochrome or maybe greyscale targets? 23.14.18 # * JdGordon wonders why kugel thinks passive agressive is a useful charactertrait 23.14.59 # pixelma: only 3 cabbies actually used the tag, and i tested all three to make sure they work, thats how! 23.15.27 # jlbiasini: what does teh OF do for control? 23.15.47 # JdGordon: what if a theme doesnt use viewports at all? then it'll work? 23.15.53 # yes 23.16.10 # looks like I can work around with %xd'ing it 23.16.18 # saratoga: scrolling gesture and virtual button 23.16.37 # and volume while locked 23.16.47 # is the eventual plan to do something like that in rockbox, or to try and make it work more like touchscreen targets? 23.16.48 # but then I could just use %xl instead 23.16.51 Join thegeek [0] (~thegeek@222.43.202.84.customer.cdi.no) 23.17.13 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 23.17.18 # JdGordon: ok, that's all I wanted to know... speaking of passive aggressiveness though 23.17.54 # I would like to work on gesture but on a more systematic approach that would allow to have it also on any touch device 23.18.03 # but I'm for from it 23.18.46 # hmm 23.19.11 # my plan would be first to see if I can find a way to have a stable double touch on the rmi driver that pamaury wrote 23.20.24 # strange issue. I see some pixel garbage with %pv and transparent images (both image and backdrop). the garbage is not there when displaying the images individually 23.20.35 # then I think that I would write some interface that any touch device could use unstead of virtual botton and implement gesture on it 23.21.21 # http://imagebin.org/202020 23.21.28 # bingo for the imagebin id! 23.21.31 # then I will have to find a way to pass touchdevice info through USB to uisimulator 23.21.46 # for test purpose 23.22.02 # jlbiasini: ok that seems sensible, and would probably allow for changing how the lock function works in a neat way 23.22.03 # then I would start implementing gesture 23.22.31 # yes probably 23.22.51 # and it' about works for years!! :D 23.23.08 Quit hillshum (Ping timeout: 260 seconds) 23.25.44 # If this seems reasonable to ask I would ask on the dev about those locking stuff. But I'm a bit intimidated because of the history of the volume in hold... 23.26.10 # but anyway I would like first to finish what I started on PLA 23.28.30 Join prof_wolfff [0] (~user1@82.159.9.243.dyn.user.ono.com) 23.28.47 Join hillshum [0] (~hillshum@71-219-57-106.slkc.qwest.net) 23.29.34 # with new platforms we have to reevaluate old design choices 23.29.39 # oh I have a question regarding cabbie theme: on fuze+ the arrow that represent random never get lighted even when random play is on. Is it on all target so or is it another problem with fuze+ 23.30.10 # LambdaCalculus37: USB is still broken for some nano2g, i remember my last commit worked for you but not for saint. and apparently even with that commit reverted there are still problems 23.30.21 # first thing would be to find what is the last working commit 23.31.01 # saratoga: the problem with gesture will be to see how or if we can/want to combinate the gesture with the old button way or simply start on a new interface system 23.31.04 # i could do that easily if i had one in my hands. how much is shipping to eastern Canada? 23.31.33 # because the button way can be really a problem to implement gesture on it 23.31.53 # jlbiasini: couldn't you implement gestures as button presses? 23.32.06 # like any _repeat button would conflict 23.32.18 # basically have the driver detect that you swipped right and then have it press the button corrisponding to right in software 23.32.56 # yes you'll still have to go through and come up with a keymap, but provided you can get things like gesture detection working i don't see that its a huge problem to come up with a keymap 23.33.58 # well for examp a quick turn around would be to simply move all long press button to double click on gesture device 23.34.58 # but as i said there really no use discussing this because it's like in year that I might be ready to start something on this. There is a lot of work to do before 23.35.13 *** Saving seen data "./dancer.seen" 23.35.23 # the implementation of a testing method is mandatory 23.35.36 # because it would take too long to test on device? 23.36.28 # yes there are a buch of value to test individualy if you want to have it working properly 23.37.21 # if getting USB HID working is difficult, you could probably also log the output of the sensor to disk when making certain gestures and then develop code to recognize the prerecorded gestures 23.37.26 # especially if your code has to make difference between several stuff like virtual button, gesture and so on 23.38.00 # that a good idea 23.38.08 # what does the output of the sensor look like? 23.38.16 # do it give you absolute position? 23.39.28 # jlbiasini - wasn't the issue with the repeat icon and solution to this mentioned in the anythingbutipod forums? I seem to remember something like this and thought the fix was committed but I could be wrong (or maybe it was for another screen size with a similar problem) 23.39.44 # on fuze+ we have alot of stuff absolute, relative, even gesture like double click, tap and hold... But if we want to have a general interface to handle several device only relying on absolute would be better I guess 23.40.05 # yeah but what is the format of the data you get back from teh sensor? 23.40.30 # a wrong image positioning in the viewport it was, if I remember correctly 23.40.35 # int? I guess 23.41.46 # anyway if we build this interface uppon the driver we can set it to be what ever we want 23.44.59 # i mean, what is the sensor actually telling you when you poll it? a bitmap of touched pixels, a preprocessed list of motions, something else? 23.45.08 # gevaerts: good point :) 23.50.00 Join enthdegree [0] (~BitchX@unaffiliated/enthdegree) 23.50.24 # saratoga: I didn't looked precisely yet. Like I said this is only long term plan - And most of wich I will have to learn before starting. the sensor get handle through the rmi driver into the button-target driver for what I see in the code of fuzeplus-button.c this is mostly int but I must admit that I'm not even sure that it is what you're talking about... 23.51.08 # any sensor is going to return integers (since sensor outputs are by definition integers until they're processed) 23.51.41 # but does the sensor give you raw data, or is it doing processing on the data before spitting it out? 23.51.42 # gesture are preprocessed list of motion 23.51.48 # ah ok thats what i'm asking 23.51.59 # so its not even really a sensor you have access to, but some signal processor? 23.52.49 # I'm not sure I prefer not to say anything because I really don't know more 23.52.57 # ok 23.53.18 # well if the sensor is doing a lot of the hard processing to figure out the motion for you, then implementing basic gestures might be pretty easy 23.53.21 # pamaury wrote the stuff, you would better ask him 23.53.59 # saratoga: yes but the idea would be to write a general interface 23.54.02 # for instance if it just gives you a motion vector, detecting a swipe or a circle motion might be very little code (although probably getting it to work very dependably might take a lot more effort) 23.54.54 # yes this could be implemented as a more generic gesture interface that receives motions from a touch driver and then maps them to button presses that the rest of rockbox understands 23.55.24 # so that things like rockbox on android could also use gestures 23.55.24 # I think the button-target of any target using the gesture system should implement some absolute position fonction that the interface would use to interpret gesture over it 23.56.14 # but like I said only idea for now 23.57.41 # ok bedtime 23.57.45 # :) 23.57.53 Part jlbiasini