| 00:01:48 | | Quit jlbiasini (Quit: jlbiasini) |
| 00:19:55 | | Nick SuperBrainAK is now known as DormantBrain (~andy@shared02.balt01.cd.2g2u.net) |
| 00:45:40 | | Quit bertrik (Remote host closed the connection) |
| 00:49:14 | | Quit thomasjfox_ (Quit: Konversation terminated!) |
| 00:57:46 | | Quit ender` (Quit: #include <unistd.h> | #define Bork for | #define bork fork() | int main() { Bork(bork ;; bork) bork; }) |
| 01:00 |
| 01:07:04 | | Quit pamaury (Ping timeout: 245 seconds) |
| 01:22:27 | [Saint] | lebellium: I admit, that behavior is non-obvious. |
| 01:22:52 | [Saint] | I guess some RTC will present a bullshit time/date if RTC is non-set. |
| 01:23:08 | [Saint] | For instance: 01:01:1970 00:00 |
| 01:23:19 | [Saint] | ^ a fairly common one. |
| 01:23:45 | lebellium | I guess I already got −−:−− |
| 01:23:47 | [Saint] | Apparently when <target_in_question>'s RTC is non-set, its simply ":" |
| 01:23:56 | [Saint] | ...which is kinda annoying. |
| 01:24:24 | [Saint] | But, anyway, yes...I did forget about the last tuple of that tag. |
| 01:24:52 | lebellium | yes sure. But then this tag is not what I wanted. I wanted to add a clock for RTC targets (Archos Recorder) and display another thing on my Ondio |
| 01:24:59 | [Saint] | Its (iirc) <rtc is set|rtc non-set|I have no fucking idea what you're talking about> :P |
| 01:25:21 | lebellium | ah? |
| 01:25:39 | lebellium | oho! |
| 01:25:40 | lebellium | indeed |
| 01:25:42 | lebellium | :) |
| 01:25:44 | [Saint] | errr, sorry, s/set/present/ |
| 01:26:15 | lebellium | %?cc<yes|no|maybe> works |
| 01:26:20 | lebellium | that's what I wanted |
| 01:26:24 | * | [Saint] nods |
| 01:26:40 | [Saint] | yet more things I need to make clearer in the documentation. |
| 01:26:52 | lebellium | then I can use "maybe" as "there is no RTC in hardware" |
| 01:27:01 | [Saint] | There are other tags that use the last tuple similarly. |
| 01:27:08 | [Saint] | like volume and battery, for example. |
| 01:28:14 | [Saint] | %?bc<mute|1|2|3|4|5|...|"I don't even know man....I give up"> |
| 01:28:35 | lebellium | the last one is not 100%? |
| 01:28:42 | [Saint] | No. |
| 01:28:45 | lebellium | max volume* |
| 01:28:58 | lebellium | heh |
| 01:29:02 | lebellium | who knows that? :D |
| 01:29:07 | [Saint] | The very last tuple _should_ be "indeterminable" |
| 01:29:24 | lebellium | I thought this was only valid for battery and FM strength |
| 01:30:15 | [Saint] | Not being able to determine the current volume is incredibly unlikely, but iirc, the tag does behave this way. |
| 01:30:22 | lebellium | hum |
| 01:30:30 | lebellium | Should I update 10 themes? :S |
| 01:31:15 | [Saint] | No, its not really an issue, more of a "safety net" I believe. Conditions will usually work happily if one or more tuples are stripped from the end of it. |
| 01:32:01 | [Saint] | the volume tag usually catches people out compared to how the think it works. |
| 01:32:37 | [Saint] | <mute|1|2|3|4|5|...|line level|ranges above line level|indeterminable> |
| 01:32:45 | lebellium | I thought I used cabbiev2 as example for volume. But my 1st theme was back to 2011, so I don't remember exactly |
| 01:33:33 | [Saint] | It wouldn't surprise me at all if cabbie didn't include this, as not knowing the current volume is incredibly unlikely. |
| 01:34:20 | [Saint] | I notice lots of user-built themes forget to include tuples for line level and ranges above line level. |
| 01:34:41 | [Saint] | so their volume gauges only go as high as -1dB |
| 01:35:18 | lebellium | that probably means the documentation is not clear enough or they copied a bad theme :D |
| 01:35:47 | [Saint] | Or both. At least I can do something about the former. |
| 01:35:55 | [Saint] | The latter is harder to combat. |
| 01:35:57 | [Saint] | :) |
| 01:46:18 | *** | Saving seen data "./dancer.seen" |
| 01:47:01 | * | [Saint] plays with his new 240GB iPod Video |
| 02:00 |
| 02:00:14 | | Join __jae__ [0] (~jae@dedicated.jaerhard.com) |
| 02:02:03 | | Quit DormantBrain (Ping timeout: 245 seconds) |
| 02:04:00 | | Join DormantBrain [0] (~andy@74.112.203.135) |
| 02:04:21 | | Nick DormantBrain is now known as SuperBrainAK (~andy@74.112.203.135) |
| 02:04:31 | | Quit __jae__ (Ping timeout: 240 seconds) |
| 02:09:45 | | Quit lebellium (Quit: ChatZilla 0.9.90.1 [Firefox 24.0/20130822154523]) |
| 02:33:55 | | Quit habys (Quit: WeeChat 0.4.1) |
| 02:42:41 | | Quit crose (Quit: Leaving) |
| 02:43:11 | | Join habys [0] (~luke@arikui.org) |
| 03:00 |
| 03:20:21 | | Nick jmspeex_ is now known as jmspeex (jm@mf4-xiph.osuosl.org) |
| 03:35:40 | polemon__ | hey guys, what is the status of the USB issue for the Ipod Nano 2G? |
| 03:46:19 | *** | Saving seen data "./dancer.seen" |
| 03:58:51 | Jinx | vedos: interesting... thanks for sharing the information |
| 03:59:06 | Jinx | at least apparently you can boot to original FW without reflashing? |
| 04:00 |
| 04:25:32 | | Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) |
| 04:25:42 | | Quit amiconn (Disconnected by services) |
| 04:25:49 | | Quit pixelma (Disconnected by services) |
| 04:25:50 | | Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) |
| 04:25:52 | | Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) |
| 04:28:21 | | Quit uwe_ (Read error: Operation timed out) |
| 04:30:39 | | Join uwe_ [0] (~uwe_@dslb-188-105-027-013.pools.arcor-ip.net) |
| 05:00 |
| 05:12:57 | | Quit TheSeven (Disconnected by services) |
| 05:13:07 | | Join [7] [0] (~quassel@rockbox/developer/TheSeven) |
| 05:46:23 | *** | Saving seen data "./dancer.seen" |
| 05:46:42 | | Quit [Saint] (Remote host closed the connection) |
| 05:47:51 | | Join [Saint] [0] (~saint@rockbox/user/saint) |
| 06:00 |
| 06:21:15 | | Join advcomp2019__ [0] (~advcomp20@65-131-164-27.sxct.qwest.net) |
| 06:21:15 | | Quit advcomp2019__ (Changing host) |
| 06:21:15 | | Join advcomp2019__ [0] (~advcomp20@unaffiliated/advcomp2019) |
| 06:24:27 | | Quit advcomp2019_ (Ping timeout: 256 seconds) |
| 07:00 |
| 07:33:42 | | Join saratoga [0] (123e1c32@gateway/web/freenode/ip.18.62.28.50) |
| 07:34:08 | saratoga | who has access to the gerrit config? changing the launch page to "http://gerrit.rockbox.org/r/#/q/status:open+project:rockbox,n,z" would prevent showing the sandbox entries |
| 07:34:16 | saratoga | http://gerrit.rockbox.org/r/#/q/status:open+project:rockbox,n,z rather |
| 07:38:44 | | Nick SuperBrainAK is now known as DormantBrain (~andy@74.112.203.135) |
| 07:46:25 | *** | Saving seen data "./dancer.seen" |
| 08:00 |
| 08:03:46 | | Quit soap (Ping timeout: 260 seconds) |
| 08:07:30 | [Saint] | Holy crap the iPod Video boots fast with nothing but rockbox in the OSOS |
| 08:07:37 | [Saint] | No dual-boot, but...meh. |
| 08:07:55 | [Saint] | Its about 4~5 seconds faster than stock Rockbox install. |
| 08:09:45 | * | [Saint] is very much liking his new iPod Video |
| 08:09:56 | [Saint] | ...if only it had a better CPU |
| 08:11:32 | [Saint] | I was lucky enough to get one of the 64MB RAM models. The pawn show I got it from apparently just looked at the serial number to determine the specification. It was listed as being 80GB, but it has the 240GB aftermarket Toshiba disk in it, and an aftermarket 800mAh battery. |
| 08:11:48 | [Saint] | All for $70 NZD, quite the score. |
| 08:14:57 | copper | nice |
| 08:15:32 | [Saint] | I would've been happy if it was stock, as it is in nice condition. |
| 08:15:41 | copper | the HDD in my Classic makes it uncomfortably slower than my Fuze+ though |
| 08:15:49 | [Saint] | The aftermarket parts were a very welcomed surprise, though. |
| 08:16:23 | [Saint] | ALso, yes...HDD targets do seem very slow when you're used to flash storage. |
| 08:16:27 | copper | seems like I'm always waiting for the HDD to spin down |
| 08:16:46 | [Saint] | But, I don't mind the sacrifice in speed for the additional capacity it brings. |
| 08:17:00 | [Saint] | y'know there's a spin-down setting, right? |
| 08:17:09 | [Saint] | set it to 3 seconds. |
| 08:17:41 | [Saint] | (iirc, that's the lowest selection available) |
| 08:18:04 | copper | I meant it's always loading stuff |
| 08:18:08 | copper | no idea what |
| 08:18:38 | [Saint] | Ah. |
| 08:18:56 | copper | and it feels like I have to handle it like a fragile child with a bone disease or something |
| 08:19:14 | [Saint] | Mine behave fine. |
| 08:19:19 | * | [Saint] shrugs |
| 08:19:44 | [Saint] | ...now to transfer 240GB at ~6MB/s |
| 08:19:48 | [Saint] | :-S |
| 08:19:55 | copper | mine goes to 20! |
| 08:20:22 | [Saint] | My Classic does too, this Video doesn't seem terribly speedy. |
| 08:34:54 | [Saint] | Booting two iPod Videos next to each other, one with a completely stock install, and the other with Rockbox is OSOS alone makes for quite the dramatic comparison. |
| 08:35:21 | [Saint] | The OSOS install has booted and spun down the HDD before the stock install finished booting. |
| 08:36:54 | copper | what's OSOS? |
| 08:40:07 | * | [Saint] forgets the exact acronym |
| 08:41:03 | [Saint] | Have a look at http://www.rockbox.org/wiki/IpodPatcher#Advanced_usage |
| 08:42:21 | [Saint] | The installation method I use is "4) OSOS contains only Rockbox" |
| 08:44:40 | | Join bertrik [0] (~quassel@rockbox/developer/bertrik) |
| 09:00 |
| 09:05:44 | | Join Zagor [242] (~bjst@rockbox/developer/Zagor) |
| 09:09:55 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 09:13:46 | | Quit bertrik (Remote host closed the connection) |
| 09:16:39 | | Join soap [0] (~soap@cpe-174-102-96-10.woh.res.rr.com) |
| 09:16:39 | | Quit soap (Changing host) |
| 09:16:39 | | Join soap [0] (~soap@rockbox/staff/soap) |
| 09:19:07 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 09:25:53 | | Join LinusN [0] (linus@giant.haxx.se) |
| 09:34:58 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 09:46:29 | *** | Saving seen data "./dancer.seen" |
| 10:00 |
| 10:08:01 | | Quit saratoga (Quit: Page closed) |
| 10:27:59 | | Join einhirn [0] (~Miranda@p4FC74B3B.dip0.t-ipconnect.de) |
| 10:32:38 | | Quit einhirn (Ping timeout: 256 seconds) |
| 10:49:41 | | Quit pamaury (Ping timeout: 264 seconds) |
| 11:00 |
| 11:07:06 | | Join krabador [0] (~krabador_@unaffiliated/krabador) |
| 11:17:55 | | Quit bluebrother (Disconnected by services) |
| 11:18:02 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
| 11:19:09 | | Quit fs-bluebot (Ping timeout: 246 seconds) |
| 11:20:26 | | Join fs-bluebot [0] (~fs-bluebo@f053155007.adsl.alicedsl.de) |
| 11:21:50 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 11:26:23 | | Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) |
| 11:28:42 | | Join jlbiasini [0] (~metaphysi@ABordeaux-651-1-197-94.w86-201.abo.wanadoo.fr) |
| 11:30:09 | | Join __jae__ [0] (~jae@80.82.209.27) |
| 11:30:34 | wodz | [7]: ping |
| 11:34:37 | | Quit __jae__ (Ping timeout: 240 seconds) |
| 11:45:31 | pamaury | wodz: yes? |
| 11:46:31 | *** | Saving seen data "./dancer.seen" |
| 11:47:35 | jlbiasini | pamaury: we should wait for kugel to have a look to it too, but if you want to have a look yourself, I redid my g#569... |
| 11:47:38 | fs-bluebot | Gerrit review #569 at http://gerrit.rockbox.org/r/569 : touchpad: Disable touchpad on softlock. by Jean-Louis Biasini (changes/69/569/30) |
| 11:48:44 | wodz | pamaury: which crt0.S you were referring to when talking about rk27xx hwstub port? |
| 11:49:28 | wodz | pamaury: And another question, how to define structure in IDA which contains another structure as a member? |
| 11:50:23 | | Join lebellium [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) |
| 11:54:09 | | Join crose [0] (~John@116-66-190-109.dsl.ovh.fr) |
| 12:00 |
| 12:56:19 | | Quit rdn (Remote host closed the connection) |
| 12:58:24 | jlbiasini | pamaury: could you test g#577 on your device? Also if you know something about the question given as comment that would help... |
| 12:58:26 | fs-bluebot | Gerrit review #577 at http://gerrit.rockbox.org/r/577 : touchscreen: softlock touch settings implementation by Jean-Louis Biasini (changes/77/577/5) |
| 13:00 |
| 13:18:07 | kugel | jlbiasini: what about the simulator? |
| 13:18:31 | copper | how would he test touchpad sensitivity in the sim? |
| 13:18:39 | copper | o_O |
| 13:18:51 | copper | er |
| 13:18:56 | copper | I misread that |
| 13:25:17 | | Join __jae__ [0] (~jae@dedicated.jaerhard.com) |
| 13:30:03 | | Quit lebellium (Quit: ChatZilla 0.9.90.1 [Firefox 24.0/20130822154523]) |
| 13:31:25 | pamaury | wodz: the crt0.S in hwstub/stub/, there is only one... |
| 13:31:41 | pamaury | wodz: to create substructures, create a field (with 'd') and then press Alt+Q |
| 13:33:25 | jlbiasini | kugel: thanks very much for your comment! The simulator exclusion is beccause the driver part doesn't get compilated in the simulator leading to a compilation error because the _device doesn't get declared/defined pamaury told me to exclude it to solve this but pehraps do you have a better idea? |
| 13:34:37 | wodz | pamaury: wait but this crt0.S only setups stack, clear bss and jumps to main so what do you really commented out? |
| 13:35:42 | pamaury | hum, really ? that must be on my working copy then...but I thought I pushed it to the trunk |
| 13:41:18 | kugel | jlbiasini: should be properly simulated |
| 13:46:32 | *** | Saving seen data "./dancer.seen" |
| 13:47:02 | pamaury | wodz: the stub relocates itself in HEAD |
| 13:47:57 | kugel | jlbiasini, pamaury: fwiw, I would like to discuss why/if there's a need for a setting for this |
| 13:48:21 | wodz | pamaury: will look today evening |
| 13:48:28 | pamaury | kugel: what do you suggest, make it the default behaviour ? |
| 13:48:39 | kugel | since it only affects the fuze+, an unstable port, changing existing behavior is acceptable |
| 13:49:21 | kugel | yes, the new behavior makes more sense than the because a touchpad is a lot more sensitive than tactile buttons |
| 13:49:49 | kugel | s/than// |
| 13:50:00 | jlbiasini | kugel: why not but the discussion already occured. But as I'm trying to expand that behaviour to touchscreen target too (see g#577) it would also change behaviour of those target |
| 13:50:03 | fs-bluebot | Gerrit review #577 at http://gerrit.rockbox.org/r/577 : touchscreen: softlock touch settings implementation by Jean-Louis Biasini (changes/77/577/5) |
| 13:50:12 | pamaury | that's fine for me, but what about touchscreen then ? |
| 13:50:52 | kugel | do we have touchscreen targets wihtout hardware lock button? |
| 13:51:04 | jlbiasini | kugel: yes |
| 13:51:08 | jlbiasini | ondav777 |
| 13:51:12 | jlbiasini | at least |
| 13:51:27 | jlbiasini | zen-xfi2 |
| 13:51:35 | jlbiasini | android/sdl |
| 13:51:37 | kugel | the onda's aren't even unstable |
| 13:52:00 | kugel | we have no stable touchcreen targets, we're pretty free to experiment I'd say |
| 13:52:12 | jlbiasini | great then |
| 13:53:18 | jlbiasini | I ws of the idea that a setting was useless in the first place, but the do-not-change-usual-behaviour kind of scare pamaury and me |
| 13:53:36 | kugel | obviously we need to make sure there's still a way to unlock |
| 13:54:13 | pamaury | that's the keymapper's job ;) But yeah I need everyone wants the device to behave this way nowadays, and you're right, there is no really stable touchscreen targert |
| 13:54:15 | pamaury | *target |
| 13:54:47 | jlbiasini | anyway there is also another setting comming soon: the lock only touchdev on softlock |
| 13:55:41 | kugel | jlbiasini: why would you want that? |
| 13:55:51 | jlbiasini | and I would like to have touchpad sensitiivity enlarge to get used by touchscreen if possible. I think it maks sense to have those general touch setting together |
| 13:55:52 | kugel | let me guess: use volume buttons while screen off |
| 13:56:04 | jlbiasini | exactly |
| 13:56:39 | kugel | that's an old problem, we ideally want a generic solution to that. sansa clips and other targets have this issue as well |
| 13:57:29 | jlbiasini | there is a lot of difference betwenn touchpad and hard key. So people often want to have their touchpad lock and still want to use hard button. As it really depend on people/situtation a setting is mandatory on this |
| 13:57:40 | kugel | I liked the behavior of CM a few versions ago: when the screen is off the volume buttons still work and a long press on those skips tracks |
| 13:58:02 | jlbiasini | CM? |
| 13:58:09 | kugel | cyanogenmod |
| 13:59:28 | jlbiasini | I think that we should start be the obvious hard and virtual keys have to be seperated |
| 13:59:47 | jlbiasini | then we can add a different keympas on hold |
| 14:00 |
| 14:00:11 | kugel | the clip have only hard keys |
| 14:00:41 | pamaury | the right solution is probably a different keymap on hold, virtual vs hard is not sufficient |
| 14:00:46 | kugel | I think this has very little to do with touch or not |
| 14:00:58 | jlbiasini | so it's another problem how do you call that, othogonality :p :D |
| 14:01:27 | jlbiasini | this could be handle with a special keymaps on hold |
| 14:01:46 | pamaury | so let's go back to the current patch to implement the lock: what do we need to make that work on the sim and to be as clean as possible and to handle touchpad and touchscreen ? |
| 14:01:47 | jlbiasini | I was also thinking about something like that before |
| 14:02:31 | jlbiasini | yes because I'm not familliar at all with simulator so i'm a bit lost on this... |
| 14:03:00 | pamaury | I don't really like the touchpad_filter_enabled of the last commit, I don't get why it is there |
| 14:03:01 | kugel | a separate keymap (in particular one that doesnt depend on the current context/screen) when locked seems sensible to me |
| 14:03:21 | pamaury | s/commit/âtch |
| 14:03:23 | pamaury | *patch |
| 14:03:57 | jlbiasini | pamaury: it an imitation of the touchscreen_to_pixel implementation |
| 14:04:44 | pamaury | yes and I really dislike this one, this has always make the simulator even more tricky to work with touchscreen |
| 14:05:03 | jlbiasini | it filter the driver output based on BUTTON_TOUCHPAD and thus provides a generic way to silent touchpad evenn on touchpad without a knowned power saving function |
| 14:05:57 | jlbiasini | very usefull actually but pehraps there would be a better way to implement it |
| 14:06:45 | kugel | as I understand it it basically there to filter out BUTTON_TOUCHPAD (a bitmask) buttons and still let tactile keys through |
| 14:06:46 | pamaury | I don't like it because it puts more logic in the low level driver, which you then have to emulate in the simulator |
| 14:07:13 | jlbiasini | after all I'm only rewriting the whole stuff for the second time :D so if there are better idea on the implementation please, tell me... |
| 14:08:51 | jlbiasini | I agree that not being able to test the implementation in the simulator is really a pull down |
| 14:09:17 | jlbiasini | especially when it's something that would impact about 10 different targets... |
| 14:09:39 | | Join einhirn [0] (Miranda@bsod.vpn.tu-clausthal.de) |
| 14:10:28 | pamaury | what about this: in action.c, we call touchpad_enable_device (#ifdef TOUCHPAD) and touchscreen_enable_device(#ifdef TOUCHSCREEN) |
| 14:10:53 | pamaury | for native targets, we implement touch{pad,touchscreen}_enable_device (with power management for fuze+ and boolean for others) |
| 14:11:09 | pamaury | for hosted, we add them in firmware/hosted/sdl/button.c |
| 14:11:23 | jlbiasini | I have a question about drivers actually: why doesn't android build have a target-button.c? And where am I suppose to declare my touchscreen_enable_device then? |
| 14:11:34 | pamaury | and for this to work, we need a define of the touchpad buttons to filter them out in the sim |
| 14:11:49 | kugel | pamaury: a wrapper in button.c would be ok...that does compile for the sim doesnt it? |
| 14:12:05 | pamaury | yes I think it does |
| 14:12:30 | jlbiasini | I totally agree with that except I don't get it at all... |
| 14:12:38 | pamaury | in any case, we will need some define to tell the simulator which buttons are the touchpad and which one aren't... |
| 14:12:39 | kugel | jlbiasini: it has a button-android.c somewhere |
| 14:12:57 | jlbiasini | yes but no button-android.h |
| 14:13:06 | kugel | pamaury: right, that's in button-target.h which is seen by the sim |
| 14:13:51 | kugel | jlbiasini: it's called button-target.h |
| 14:14:29 | jlbiasini | but there are none in the android dir I think, I didn't find any |
| 14:14:36 | pamaury | ok, so we keep the BUTTON_TOUCHPAD define in button-target.h, drop the filter function and implement touchpad/screen_enable_device in hosted/sdl button driver which in turn uses a boolean and the BUTTON_TOUCHPAD define |
| 14:14:45 | pamaury | and for android, well I don't know |
| 14:16:01 | kugel | jlbiasini: it's in the app subdir |
| 14:16:23 | pamaury | for android I guess we can filter touchscreen in hosted/android/button.c:button_read_device |
| 14:16:28 | kugel | pamaury: I think so |
| 14:16:43 | pamaury | does the android port has a softlock mechanism ? |
| 14:16:58 | pamaury | or does it rely on the OS ? |
| 14:17:23 | jlbiasini | yes but I thinks this one is more app related and doesn't get include in button_android.c |
| 14:17:26 | kugel | not that I'm aware of |
| 14:18:28 | jlbiasini | in sdl there is button-sdl.h button-sdl.c apps/button-target.h app/button-application.c |
| 14:18:37 | pamaury | kugel: jlbiasini: let me have a try at this, I'll post the patch in a 5 minutes |
| 14:18:48 | jlbiasini | ok |
| 14:21:24 | jlbiasini | kugel: actually button-android.c include buttonmap.h not very consistent but we can put it there |
| 14:22:21 | kugel | jlbiasini: button-target.h is always included, implicitely via button.h |
| 14:22:44 | kugel | (if not its a bug) |
| 14:22:51 | jlbiasini | ok |
| 14:24:58 | jlbiasini | pamaury: what I don't get is how you are going to get generic silent touchpad when no power saving is avalaible, but I guess that I would just wait to see your implementation before complaining |
| 14:28:06 | pamaury | we implement it for every target which has touchpad/touchscreen, ie no generic |
| 14:29:31 | jlbiasini | the point of the filter was precisely to have a generic function... If not I can implement it myself it's not really dificult... |
| 14:30:40 | jlbiasini | at least we could have a filter in action.c |
| 14:31:00 | pamaury | I don't really like it, from the point of view of someone not knowing how it works, if you split it in many places it gets hard to understand. I think it's just simpler this way: for a new port just implement touch*_enable_device, that's one boolean for a start so very easy and for touchpad just add an extra define for the simulator |
| 14:31:52 | jlbiasini | I was thinking of describing the code in the wiki after having implemented it |
| 14:32:06 | pamaury | just wait for my code and then comment ;) |
| 14:32:08 | [7] | wodz: pong |
| 14:32:12 | jlbiasini | ok |
| 14:33:38 | wodz | [7]: pamaury answered my question already (about structs in ida) |
| 14:33:43 | jlbiasini | but I think the generic way is really important else It would basically be a f+ functionnality and there not need to paly around with all kind of ifdef everywhere |
| 14:34:30 | | Join robin0800 [0] (~Robin0800@cpc1-brig15-2-0-cust755.3-3.cable.virginmedia.com) |
| 14:38:00 | | Join amayer [0] (~amayer@mail.weberadvertising.com) |
| 14:41:03 | * | jlbiasini starts to understand what is pamaury is talking about... |
| 14:47:33 | pamaury | may I suggest something at the same time ? It requires to answer one question: what is a touchpad ? |
| 14:48:02 | pamaury | because at the same time we do this, we could also report the touchpad absolute position in button data |
| 14:48:19 | pamaury | it will be unused for now but if one day someone wants to implement gestures... |
| 14:49:31 | pamaury | we could even move the button interpretation from the drive to touchpad.c, using touchpad areas just like with touchscreen |
| 14:49:36 | pamaury | *driver |
| 14:50:26 | jlbiasini | pamaury: for the absolute report I was also thinking about something like that |
| 14:51:07 | pamaury | kugel: any thoughts ? |
| 14:51:54 | jlbiasini | for the second part it seems to me difficult because most touchpad device at least till now are at least partly button oriented, even the fuze+ that is probably the more advanced touchpad target we have for now |
| 14:52:51 | jlbiasini | ie having generic mapping like on touchscreen doesn't really make sense IMO |
| 14:53:16 | pamaury | not generic, generic parser |
| 14:53:38 | pamaury | each target defines regions for buttons and touchpad.c lookup this mapping to find the button |
| 14:53:51 | pamaury | it is how it works on the simulator btw |
| 14:56:08 | | Quit kugel (Remote host closed the connection) |
| 14:56:16 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 14:57:39 | jlbiasini | pamaury: yes you are right this definitely makes sense but for what I understand f+ is for now the only real touchpad device. Others are merely a combination of separated touch element |
| 14:58:08 | jlbiasini | so I don't know if it's worth to implement such a thing for only one target |
| 14:59:40 | | Quit robin0800 (Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/) |
| 14:59:47 | pamaury | I have some potential targets in mind which have a touchpad: samsung YP-Q2, YP-T10 too |
| 15:00 |
| 15:02:03 | jlbiasini | ok then it would makes sense... |
| 15:02:42 | pamaury | maybe that should be part of another commit but it's better to think about this ahead |
| 15:02:52 | pamaury | so you're right, a filter like function it probably better |
| 15:04:35 | jlbiasini | I guess that touchpad.c is going to be even closer to touchscreen.c so? |
| 15:05:06 | pamaury | yes |
| 15:05:57 | pamaury | which worries me a bit |
| 15:06:24 | jlbiasini | usine à gaz spirit :D |
| 15:07:04 | copper | what's the english equivalent of that btw? |
| 15:07:23 | copper | the kitchen sink? |
| 15:07:43 | pamaury | the thing is that touchscreen.c is mostly screen agnostic except for grid mode |
| 15:08:06 | pamaury | and I can't think of a device with both touchpad and touchscreen |
| 15:08:39 | jlbiasini | what do you mean by "screen agnostic" |
| 15:09:12 | pamaury | it doesn't care that it is a touchscreen or a touchpad |
| 15:09:39 | pamaury | it's mostly in apps/ and button.c that the fact that a touchscreen is a touchscreen is used |
| 15:10:42 | jlbiasini | as a matter of fact a lot of touch function could be shared between all touch device |
| 15:16:18 | jlbiasini | pamaury: I think we should first poost on the mailing list on that and wait because else it's goning to end up with people coming it the last minute to say that it ain't right |
| 15:16:37 | jlbiasini | gee! this think is never to end up in the tree... |
| 15:16:41 | jlbiasini | *thing |
| 15:17:17 | | Quit michaelni (Ping timeout: 264 seconds) |
| 15:18:43 | | Quit jlbiasini (Quit: jlbiasini) |
| 15:23:47 | | Join maruk [0] (~papier@titanium.v6.sdv.fr) |
| 15:28:58 | pamaury | jlbiasini: kugel: what about this: https://gist.github.com/pamaury/6353512 |
| 15:29:02 | pamaury | (untested) |
| 15:29:56 | | Join michaelni [0] (~michael@188-22-99-23.adsl.highway.telekom.at) |
| 15:34:09 | wodz | pamaury: ok, it is no surprise that updated crt0.S doesn't work on rk27xx. This core doesn't implement copro interface so you likely end up with data abort or something. |
| 15:34:27 | wodz | or undef instr |
| 15:34:37 | pamaury | ah, ok, I thought this |
| 15:34:50 | pamaury | so that's just a #ifdef to add then |
| 15:35:01 | pamaury | maybe I'll have time to look more in depth at the usb problem later today |
| 15:36:11 | wodz | I will have some time this evening so maybe we could colaborate |
| 15:36:47 | pamaury | yes |
| 15:46:35 | *** | Saving seen data "./dancer.seen" |
| 15:50:44 | | Quit krabador (Quit: Sto andando via) |
| 16:00 |
| 16:02:11 | | Quit Zagor (Quit: Clint excited) |
| 16:31:00 | | Quit pamaury (Ping timeout: 248 seconds) |
| 16:55:18 | | Join Zagor [242] (~bjst@rockbox/developer/Zagor) |
| 16:56:39 | | Quit shamus (Ping timeout: 240 seconds) |
| 16:56:46 | | Join shamus [0] (~shmaus@ip-206-192-194-158.marylandheights.ip.cablemo.net) |
| 16:57:31 | | Join n1s [0] (~n1s@nl118-168-30.student.uu.se) |
| 16:57:31 | | Quit n1s (Changing host) |
| 16:57:31 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
| 17:00 |
| 17:12:49 | [Saint] | Hmmmm...yah, ...nah. iPod Video definitely needs UI boosting. |
| 17:13:53 | [Saint] | I guess its the relatively large LCD and relatively small CPU making the difference. |
| 17:15:13 | [Saint] | I thought maybe it was worth seeing if I could get away with disabling it, but, nope. |
| 17:16:26 | wodz | it also gets quite a few irqs from scrollwheel |
| 17:16:39 | [Saint] | Ah. |
| 17:18:17 | [Saint] | I got away with disabling it on the Classic, initially - early on in the port - it was basically unusable without boosting on UI interaction, now however - similar to the Fuze + - the CPU almost never needs to boost under normal circumstances. |
| 17:18:49 | [Saint] | I don't think this adds up to very much power saving, though, as that SoC is quite efficient. |
| 17:19:23 | copper | scrolling lines are kinda slow on my Classic with my themes |
| 17:21:36 | | Quit Poodlemastah (Quit: ZNC - http://znc.in) |
| 17:22:34 | [Saint] | well, yay, glad that worked. |
| 17:23:10 | [Saint] | I now have an ipod bootloader that doesn't care about the Apple OS or IPL anymore. |
| 17:24:27 | [Saint] | Perfect for OSOS install - since booting the Apple OF isn't actually possible. |
| 17:24:45 | [Saint] | ...and IPL is dead. |
| 17:28:41 | | Quit wodz (Quit: Leaving) |
| 17:32:44 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 17:34:26 | | Quit petur (Quit: Nettalk6 - www.ntalk.de) |
| 17:39:43 | | Join madcat1990 [0] (~madcat199@216.185.65.74) |
| 17:44:26 | | Quit Zagor (Quit: Leaving) |
| 17:45:03 | madcat1990 | Well, I was gonna report a bug, but apparently it has been fixed in Dev builds |
| 17:45:22 | [Saint] | Huzzah. |
| 17:46:19 | madcat1990 | I don't know what it is that is doing it, but here's how to reproduce it each time in 3.13 stable, and what it shows : http://pastie.org/private/tfy4ssfub9vtlgo3ruvtwg |
| 17:46:32 | madcat1990 | Seeing that it is fixed in Dev, I don't know if I should report it or not :X |
| 17:46:36 | *** | Saving seen data "./dancer.seen" |
| 17:47:20 | [Saint] | If it is fixed in git head, don't report it, no. |
| 17:53:05 | | Nick DormantBrain is now known as SuperBrainAK (~andy@74.112.203.135) |
| 17:53:20 | madcat1990 | Fair enough, I thought the same. Just wanted to make sure in case you guys needed it documented |
| 17:54:15 | madcat1990 | Btw, have I thanked you guys for the awesome work you do, today? |
| 17:54:40 | [Saint] | Not /today/... :) |
| 17:54:58 | [Saint] | But I have seen you do so in the past. Its appreciated, I'm sure. |
| 17:56:09 | n1s | madcat1990: btw, the debug menu is not intended for users and bugs there should be expected |
| 17:56:28 | [Saint] | errr... |
| 17:56:38 | [Saint] | I don't think bugs should ever be expected. |
| 17:56:50 | [Saint] | Its not intended for users, sure, but it should work. |
| 17:57:00 | madcat1990 | [Saint], I agree wholeheartedly. It is my duty, as tester, to report any findings |
| 17:57:28 | madcat1990 | Also, I'm waiting on my next paycheck to make another donation |
| 17:57:46 | madcat1990 | >.< it has now reached the point where I find other Firmwares ugly, and dysfunctional. |
| 17:58:42 | [Saint] | One should expect to find bugs in the git head builds, possibly, and that's kinda the point of them...any reported bug is better than one that goes unnoticed, even if the user isn't technically supposed to be poking around there. :) |
| 17:58:57 | [Saint] | Anyhoo - its fixed, so - yay. :) |
| 17:59:15 | madcat1990 | I always poke around there. Especially the buffering thread one. I love to see how my device is buffering |
| 17:59:24 | [Saint] | Heh. |
| 17:59:56 | madcat1990 | And the debug scrollwheel when I had my iMini2G, loved it too, just through that one screen, I found it that the scroll wheel is nothing more than a touchpad |
| 17:59:57 | [Saint] | I only find it useful myself to check buffer allocations from the skin engine. |
| 18:00 |
| 18:00:03 | madcat1990 | not ugly magic |
| 18:00:19 | madcat1990 | Yeah =/ that engine is breaking USB on my device |
| 18:00:25 | n1s | well, i'm pretty sure there are known bugs in there that noone has cared to fix but i don't remember any specific one right now |
| 18:00:25 | madcat1990 | Default themes work fine in rockbox though |
| 18:00:36 | [Saint] | you and a lot of other people. |
| 18:00:52 | [Saint] | and cabbie working, where others don't, makes no sense at all. |
| 18:01:02 | [Saint] | I *really* wish I knew what was going on there. |
| 18:01:16 | [Saint] | like, really...really really. |
| 18:01:19 | madcat1990 | This might be a stupid suggestion, but would the size of the files make a difference? or what they contain? |
| 18:01:29 | madcat1990 | there *HAS* to be something the others use that cabbie doesn't |
| 18:01:38 | madcat1990 | or something they use more |
| 18:01:44 | madcat1990 | Thusly, breaking the skinning engine |
| 18:01:56 | [Saint] | It very well may. I don't know. My best guess is bad alignment of memory allocations. |
| 18:02:09 | madcat1990 | But that's not done through the WPSes, is it? |
| 18:02:25 | [Saint] | Why some themes slide though, even when they are vastly larger than cabbie and far more complex code, I do not know. |
| 18:02:35 | [Saint] | Additionally, simpler, smaller themes also fail. |
| 18:02:39 | [Saint] | It is baffling. |
| 18:02:48 | madcat1990 | Then its not a thing of size |
| 18:02:56 | madcat1990 | its a thing of, a parameter being used that breaks it |
| 18:03:23 | [Saint] | No, even very simple themes that are essentially exact clones of cabbie can break USB. |
| 18:03:35 | [Saint] | Its not, afaik, any one tag or combination thereof. |
| 18:03:40 | [Saint] | It is *truly* baffling. |
| 18:03:49 | [Saint] | I can't find a definite trigger. |
| 18:04:24 | [Saint] | It has excaped the attempts of about half a dozen people's serious attempts at debugging. |
| 18:05:07 | [Saint] | lots of bugs have been caught and fixed whilst looking for the cause of this one, though, so that's great. |
| 18:05:09 | madcat1990 | Has anyone tried REPLACING cabbie with another theme and attempting to replicate it? |
| 18:05:16 | madcat1990 | maybe chunks of them are being loaded into memory, and left there? |
| 18:06:08 | [Saint] | I don't think so. The way memory allocation works shouldn't allow for this. And I have looked at the bufflib allocations whilst changing themes and there is no indication of leftovers. |
| 18:06:20 | [Saint] | I honestly have NFI what is happening. |
| 18:06:24 | [Saint] | Frustrating. |
| 18:06:56 | madcat1990 | You know what you guys need? a visual representation of a device's memory |
| 18:07:25 | madcat1990 | something along the lines of this : https://www.youtube.com/watch?v=tjcvR5McmSg |
| 18:11:42 | | Join polemon_ [0] (~polemon@g224097173.adsl.alicedsl.de) |
| 18:12:11 | | Join rdn [0] (~oop@cpe-69-204-124-212.buffalo.res.rr.com) |
| 18:14:41 | | Quit polemon__ (Ping timeout: 240 seconds) |
| 18:18:49 | | Join Strife89 [0] (~Strife89@2602:306:250f:2289:10e6:66d5:5350:6cbc) |
| 18:21:09 | | Join bertrik [0] (~quassel@rockbox/developer/bertrik) |
| 18:21:32 | | Join wodz [0] (~wodz@87-207-223-0.dynamic.chello.pl) |
| 18:22:41 | wodz | madcat1990: This is awersome. You need full system emulator though. We don't have such thing for any of our targets. Writing one is HUUUUGE task. |
| 18:23:32 | madcat1990 | I know. But it'd solve most of our debugging problems. :) |
| 18:24:00 | wodz | Not really. |
| 18:24:25 | wodz | there are things you cant relibly emulate |
| 18:25:23 | Bagder | there are? |
| 18:25:32 | madcat1990 | Noise? |
| 18:27:08 | wodz | ok, 'can't' is unfortunate 'are hard to' is better |
| 18:27:33 | Torne | Well, there's *lots* of things we can't emulate because we don't know how they actually work |
| 18:27:49 | Torne | writing a full system emulator for a system that you don't ahve docs for requires assuming that your reverse-engineering is correct :) |
| 18:28:08 | Bagder | true, but it would also help the reverse-engineering! |
| 18:28:34 | madcat1990 | Bagder, if anything it'd prove ours wrong. |
| 18:28:53 | Torne | obviously there are classes of bugs you can still catch even then, but some of the time you are just begging the question :) |
| 18:30:16 | madcat1990 | I really doubt there's an easy way to emulate ALL these devices. |
| 18:30:43 | madcat1990 | Best thing to do is replicate Rockbox's behavior on them, but that won't help us much |
| 18:30:55 | madcat1990 | Though, if by some chance, we can make a memory dump through USB |
| 18:30:58 | madcat1990 | and see what's happening?.. |
| 18:31:16 | wodz | madcat1990: basically pamaury is working on this :-) |
| 18:31:51 | madcat1990 | So me and one of the devs are in the same wavelength. I'm not a complete idiot! yay |
| 18:32:34 | wodz | BUT transfering mem dump through usb means that you cannot live test rockbox usb stack (although you can take a snapshot at particular event) |
| 18:34:27 | madcat1990 | Might not live test USB stack, but you can see when the skinning engine is being naughty |
| 18:35:12 | | Join eyfour [0] (~eyfour@13.90-149-56.nextgentel.com) |
| 18:35:34 | wodz | If the bug is reproducible on f+ I think we might ask pamaury to try. |
| 18:36:31 | | Join Poodlemastah [0] (~Poodlemas@109-124-181-96.customer.t3.se) |
| 18:37:00 | madcat1990 | wodz, I can prolly ask a buddy of mine who bought one of those to test it |
| 18:39:23 | | Quit maruk (Quit: Leaving.) |
| 18:39:55 | [Saint] | It is. |
| 18:40:07 | [Saint] | ...reproducible on Fuze +, I mean. |
| 18:40:12 | wodz | great |
| 18:45:50 | pamaury | madcat1990: emulating a device like the fuze+ is really a lot of work, the documentation is very vague on a number of (crucial) points, so that probably wouldn't help much. What will help is live debugging, that we are currently trying to implement |
| 18:47:01 | madcat1990 | pamaury, I realise this. Which is why I'm saying, live USB Debugging will allow us to poke at the memory, but not live USB monitoring. But it will at least allow us to check what the skinning engine is doing |
| 18:47:04 | madcat1990 | and what's causing it to misbehave |
| 18:49:50 | wodz | pamaury: can we try to insert hwstub into rockbox and trigger it on usb connect? That way we will be able to take mem snapshot at arbitrary time |
| 18:50:05 | madcat1990 | And dump it to the SD? |
| 18:50:13 | wodz | no to PC :-) |
| 18:56:35 | | Join pretty_function [0] (~sigBART@123.252.213.72) |
| 18:57:46 | | Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
| 18:57:49 | | Join thomasjfox [0] (~thomasjfo@rockbox/developer/thomasjfox) |
| 19:00 |
| 19:00:28 | wodz | If I have struct foo_t { char a, char b, short c, char d} how it will be padded in array? I mean struct foo_t ble[100]? I guess compiler will try to guarantee halfword alignment of member c in every array item so should I expect trailing padding byte for every item? |
| 19:01:35 | pamaury | wodz: that's already more or less possible with my hwpatcher tool, although not very practical. But memory dump won't be easy to analyse either |
| 19:03:14 | wodz | I don't say it will be easy |
| 19:03:47 | wodz | pamaury: btw. what is the status of your amsv2 rom disasm? |
| 19:10:15 | | Nick SuperBrainAK is now known as DormantBrain (~andy@74.112.203.135) |
| 19:13:37 | | Quit eyfour (Quit: WeeChat 0.3.7) |
| 19:16:43 | | Quit shamus (Ping timeout: 240 seconds) |
| 19:22:07 | | Join shamus [0] (~shmaus@ip-206-192-194-158.marylandheights.ip.cablemo.net) |
| 19:26:21 | | Quit [Saint] (Remote host closed the connection) |
| 19:26:51 | | Part LinusN |
| 19:27:47 | | Join [Saint] [0] (~saint@rockbox/user/saint) |
| 19:37:17 | pamaury | wodz: haven't work on this for a while, can send you my latest progress |
| 19:39:45 | wodz | pamaury: I was just curious |
| 19:46:39 | *** | Saving seen data "./dancer.seen" |
| 19:48:48 | | Join polemon__ [0] (~polemon@e179239147.adsl.alicedsl.de) |
| 19:50:56 | | Quit polemon_ (Ping timeout: 245 seconds) |
| 19:57:47 | | Quit bertrik (Remote host closed the connection) |
| 20:00 |
| 20:51:42 | | Quit thomasjfox (Remote host closed the connection) |
| 20:54:30 | | Join thomasjfox [0] (~thomasjfo@rockbox/developer/thomasjfox) |
| 20:59:18 | | Quit pretty_function (Remote host closed the connection) |
| 21:00 |
| 21:09:13 | | Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) |
| 21:46:41 | *** | Saving seen data "./dancer.seen" |
| 21:57:45 | | Quit madcat1990 (Quit: Leaving) |
| 22:00 |
| 22:03:18 | | Quit kevku (Ping timeout: 260 seconds) |
| 22:32:16 | | Join bertrik [0] (~quassel@2001:610:76a:0:749c:5212:ba7c:37ba) |
| 22:32:16 | | Quit bertrik (Changing host) |
| 22:32:16 | | Join bertrik [0] (~quassel@rockbox/developer/bertrik) |
| 22:32:33 | | Join thomasjfox_ [0] (~thomasjfo@rockbox/developer/thomasjfox) |
| 22:32:44 | | Join jlbiasini [0] (~metaphysi@ABordeaux-651-1-197-94.w86-201.abo.wanadoo.fr) |
| 22:33:12 | jlbiasini | pamaury: ping |
| 22:34:31 | | Quit thomasjfox (Ping timeout: 276 seconds) |
| 22:34:58 | | Nick thomasjfox_ is now known as thomasjfox (~thomasjfo@rockbox/developer/thomasjfox) |
| 22:48:44 | jlbiasini | pamaury: I just tried your patch it apply cleanly but gave me a lot of bug: http://pastebin.com/HY5VCqmu (this is just the beginning I cuted the following as it was endless... |
| 22:59:44 | | Join einhirn [0] (Miranda@bsod.vpn.tu-clausthal.de) |
| 23:00 |
| 23:00:18 | | Quit Strife89 (Quit: Heading out.) |
| 23:08:43 | | Nick DormantBrain is now known as SuperBrainAK (~andy@74.112.203.135) |
| 23:16:03 | | Join dewlap [0] (~dewlap@2001:5c0:1000:a::ad7) |
| 23:17:32 | | Quit bertrik (Remote host closed the connection) |
| 23:24:30 | | Quit n1s (Quit: Ex-Chat) |
| 23:26:29 | | Quit amayer (Quit: Leaving) |
| 23:30:43 | pamaury | jlbiasini: as I said I didn't try to compile it, you have to learn how to fix this ;) In button.h I wrote #define "touchpad.h" instead of #include |
| 23:31:33 | jlbiasini | ok i'll have a look tomorrow then... |
| 23:32:04 | pamaury | trying to compile now... |
| 23:32:23 | pamaury | ok that does the work for touchpad, now touchscreen... |
| 23:33:02 | wodz | pamaury: If you find time could you check if hwstub gets past setup request at all? |
| 23:33:15 | pamaury | wodz: last time I tried it didn't |
| 23:34:02 | pamaury | jlbiasini: I have updated the patch at https://gist.github.com/pamaury/6353512 |
| 23:34:31 | wodz | pamaury: So at least we have the same behavior |
| 23:35:16 | pamaury | let me have a try now |
| 23:40:14 | pamaury | wodz: you should definitely fix the usage() of tools/scramble.c for rockchip |
| 23:40:26 | pamaury | each time I use I have to lookup the source to realise I need the -modelnum= |
| 23:41:02 | wodz | pamaury: sure, will fix it |
| 23:41:08 | pamaury | thanks |
| 23:42:28 | pamaury | hum, I get undefined instruction if I try to run it from microsd with scramble |
| 23:43:34 | pamaury | apparently the relocate code is broken on rk27xx |
| 23:44:20 | jlbiasini | pamaury: your patch work on f+ I'm givin a try on the ondav777 simulator to see on a touchscreen target |
| 23:45:21 | jlbiasini | some more compilation error, I'll see tomorrow |
| 23:45:25 | | Quit jlbiasini (Quit: jlbiasini) |
| 23:46:44 | *** | Saving seen data "./dancer.seen" |
| 23:58:21 | | Join petur [0] (~petur@rockbox/developer/petur) |
icon identifies that the person is a core developer (has commit access).