| 00:28.43 | kristianpaul | wolfspraul: if you have already tested some baterry options for M1 please let us now |
| 00:29.18 | kristianpaul | i'm carrying with me milkymist since tomorrow, so i'll not have power for main avaliable all times.. |
| 00:40.45 | *** join/#qi-hardware cladamw (~adamwang@host-65.78-43-115.dynamic.totalbb.net.tw) |
| 00:42.12 | wolfspraul | not tested |
| 00:45.45 | kristianpaul | i was thinking buy 1.5V AA rechargable batteries until get the 4.5V and see what worked :) |
| 01:07.58 | kristianpaul | wpwrak: about labsw, had you consider a cad designed case for next version? :) |
| 01:25.42 | *** join/#qi-hardware Openfree` (~Openfreer@116.228.88.131) |
| 01:48.05 | pabs3 | git rm doesn't remove non-free stuff, its still in the repo history |
| 01:52.52 | *** join/#qi-hardware wej (~j@95.211.13.35) |
| 01:58.23 | roh | well.. duh |
| 02:02.59 | *** join/#qi-hardware rejon (~rejon@li408-40.members.linode.com) |
| 02:06.10 | *** join/#qi-hardware wolfspraul (~wolfsprau@114.241.240.226) |
| 02:32.20 | wpwrak | kristianpaul: (M1 power) at least in theory, you need regulated 5V. just a battery pack will produce weird results, since things like USB and MIDI feed directly off the 5V input. |
| 02:35.01 | kristianpaul | well, i can skip MIDI not sure about USB but try avoid it |
| 02:35.14 | wpwrak | (labsw) yeah. the case may be the hardest part to source. i'm stuck at the relays, though. they should be socketed, but it seems nearly impossible to find reasonably small relays with matching sockets. |
| 02:35.47 | kristianpaul | wpwrak: i was thinking a 4,8V (1.2V 2100mhA x 4) battery pack |
| 02:37.28 | wpwrak | if your batteries are fresh, you'd even be within the USB spec :) |
| 02:38.40 | kristianpaul | ;) |
| 02:39.56 | *** join/#qi-hardware wolfspra1l (~wolfsprau@222.130.116.253) |
| 02:41.00 | *** join/#qi-hardware wolfspra1l (~wolfsprau@222.130.116.253) |
| 02:49.14 | *** join/#qi-hardware rejon (~rejon@li408-40.members.linode.com) |
| 02:52.42 | *** join/#qi-hardware Textmode (~boneidle@adsl-syd-1-124.ozonline.com.au) |
| 03:11.22 | *** join/#qi-hardware Openfree` (~Openfreer@116.228.88.131) |
| 03:26.22 | *** join/#qi-hardware rejon (~rejon@122.71.230.173) |
| 03:43.22 | *** join/#qi-hardware rejon (~rejon@jp.fabricatorz.com) |
| 04:03.56 | *** join/#qi-hardware phirsch (~phirsch@xdsl-89-0-69-176.netcologne.de) |
| 05:14.58 | *** join/#qi-hardware xwalk_ (~crosswalk@rrcs-98-102-156-195.central.biz.rr.com) |
| 05:26.55 | *** join/#qi-hardware rejon (~rejon@li408-40.members.linode.com) |
| 05:30.49 | *** join/#qi-hardware xwalk_ (~crosswalk@rrcs-98-102-156-195.central.biz.rr.com) |
| 05:38.07 | *** join/#qi-hardware xwalk_ (~crosswalk@rrcs-98-102-156-195.central.biz.rr.com) |
| 05:55.27 | *** join/#qi-hardware rejon (~rejon@122.70.120.203) |
| 06:01.53 | *** join/#qi-hardware cladamw (~adamwang@host-65.78-43-115.dynamic.totalbb.net.tw) |
| 06:04.03 | *** join/#qi-hardware rejon (~rejon@jp.fabricatorz.com) |
| 06:05.15 | *** join/#qi-hardware jekhor (~jek@46.53.195.29) |
| 06:54.00 | *** join/#qi-hardware Textmode (~boneidle@adsl-syd-1-124.ozonline.com.au) |
| 07:50.40 | qi-bot | [commit] Adam Wang: qfp.fpd: added more info about QFP48 (master) http://qi-hw.com/p/kicad-libs/6c2cafe |
| 09:09.23 | *** join/#qi-hardware wej (~j@95.211.13.35) |
| 09:19.09 | *** join/#qi-hardware rejon (~rejon@jp.fabricatorz.com) |
| 09:42.42 | *** join/#qi-hardware antoniodariuh_ (~antonioda@nat-sta-slph1.tvu.ac.uk) |
| 09:42.54 | *** join/#qi-hardware Openfree` (~Openfreer@116.228.88.131) |
| 11:35.58 | *** join/#qi-hardware Ayla (~paul@ACaen-252-1-222-82.w86-215.abo.wanadoo.fr) |
| 11:57.36 | *** join/#qi-hardware jekhor (~jek@37.214.125.130) |
| 12:13.25 | *** join/#qi-hardware ninjak (~ninjak@77.239.137.142) |
| 12:19.02 | larsc | does anybody by chance know anything about pc fan control? my laptop gives me an error at startup "Fan control". The fan is a 4wire 5V DC fan. When I apply power it starts rotating, but I don't get a feedback signal. Is this normal? |
| 12:19.30 | *** join/#qi-hardware ninjak_ (~ninjak@77.239.137.142) |
| 12:19.42 | larsc | I see pwm signals on some of the ICs pins |
| 12:23.06 | Ayla | larsc: the mobo expects a signal from the fan |
| 12:23.31 | Ayla | you can fake it with a 555 |
| 12:23.49 | Ayla | a better idea would be to change the fan if it's not working |
| 12:24.02 | larsc | it is working fine, as far as i can see |
| 12:24.28 | larsc | there is just no signal on the additional pins |
| 12:33.48 | *** join/#qi-hardware xwalk_ (~crosswalk@d47-69-35-236.try.wideopenwest.com) |
| 12:39.45 | larsc | Ayla: do you know if it would work, if I shorted control and sense? |
| 12:40.39 | Ayla | I don't think so |
| 12:42.24 | Ayla | mth: I made a couple of experimental changes on gmenu2x, I'd like you to (dis-)agree with before I push anything |
| 12:43.44 | *** join/#qi-hardware xwalk (~crosswalk@d47-69-35-236.try.wideopenwest.com) |
| 12:43.48 | larsc | Ayla: you can always push it into a 'experimental' branch |
| 12:44.08 | Ayla | hmm |
| 12:44.19 | Ayla | I could do that, but I suck at GIT :p |
| 12:44.45 | larsc | git push remote localbrach:remotebranch |
| 12:45.02 | mth | is the implementation experimental or the feature itself? |
| 12:45.21 | Ayla | for the first change, I'm not sure of the implementation |
| 12:45.46 | Ayla | the first change is a "reload()" function on the Surface object, that (when applicable) restores the content of the backbuffer, so that when fading is used (loading screen and contextual menu) the very last image is displayed as the background, and not an old image |
| 12:47.05 | Ayla | that's was not the case when rendering at 32bpp, because then the main surface is not double-buffered (as SDL does a conversion later) |
| 12:47.29 | Ayla | the experimental features are a switch to 16bpp, and a menu clock set to... 48MHz |
| 12:48.24 | mth | gmenu2x is already slow sometimes, I prefer not to clock it down further until we resolve that slowness |
| 12:48.48 | Ayla | 48MHz / 16bpp is as fast as 192MHz / 32bpp |
| 12:49.27 | mth | not when building a file list in the explorer, I think |
| 12:49.46 | mth | also some context menus take a long time to open |
| 12:50.14 | Ayla | which ones? |
| 12:50.36 | mth | I forgot, but I'll make note of it when it happens again |
| 12:50.41 | mth | it happens quite often |
| 12:51.01 | mth | I do agree with wanting to render at 16bpp, although for themes that use a lot of transparency 32bpp might look better |
| 12:51.14 | mth | what does "reload()" do exactly? |
| 12:51.43 | Ayla | memcpy(raw->pixels, backbuffer, raw->h * raw->pitch) |
| 12:54.41 | Ayla | transparency seems to work fine |
| 12:55.08 | Ayla | SDL takes care of that |
| 12:57.11 | mth | but alpha surfaces are 32 bpp anyway and when blending, the extra precision bits on the back buffer might avoid rounding errors |
| 12:58.36 | mth | RGBA surfaces with 8-bit alpha, I mean; you can have a 16bpp surface with color keyed alpha iirc, or RGBA5551 |
| 13:01.29 | Ayla | no, because the back buffer is not RGBA |
| 13:01.46 | *** join/#qi-hardware DocScrutinizer06 (~HaleBopp@openmoko/engineers/joerg) |
| 13:02.01 | *** join/#qi-hardware DocScrutinizer (~halley@openmoko/engineers/joerg) |
| 13:02.29 | mth | I mean the surface blitted onto the back buffer might be 32 bpp |
| 13:03.02 | Ayla | yes |
| 13:03.12 | Ayla | well, of course we lose a few bits of precision |
| 13:03.17 | Ayla | but that's expected |
| 13:07.14 | mth | anyway, we want to be able to render at 16bpp, whether we make that the default or not |
| 13:08.03 | mth | what is that "raw" buffer? |
| 13:08.27 | Ayla | "raw" is the name you gave to the SDL_Surface contained inside the Surface object |
| 13:09.44 | *** join/#qi-hardware DocScrutinizer05 (~HaleBopp@openmoko/engineers/joerg) |
| 13:10.32 | mth | which Surface object do you want to call it on then? |
| 13:10.34 | *** join/#qi-hardware DocScrutinizer05 (~HaleBopp@openmoko/engineers/joerg) |
| 13:11.00 | mth | what I don't understand is, why would there be an off-screen version of the current frame? |
| 13:11.14 | mth | I'd expect a repaint() rather than a reload() |
| 13:13.58 | mth | hmm, why does RGBAColor use 16 bits per component? |
| 13:17.48 | Ayla | I call it on the main Surface object, the one that corresponds to the framebuffer |
| 13:18.44 | Ayla | when using double buffering, that buffer corresponds to the one being sent to the LCD |
| 13:19.45 | mth | so the front buffer? that doesn't sound likely; SDL wouldn't give you the front buffer pointer unless you did some trickery |
| 13:20.03 | Ayla | yes, I did :p |
| 13:20.35 | Ayla | I save a pointer to raw->pixels on the "flip" function, before flipping the SDL_Surface |
| 13:20.37 | mth | that will break if we ever implement the rotating buffer via v4l2 idea |
| 13:21.12 | mth | I really prefer to repaint rather than save old frame contents |
| 13:21.49 | mth | repaint should be easier than restore and if it is not, that is something that should be fixed and will improve the code overall |
| 13:23.31 | Ayla | I did restore because repainting really isn't easy |
| 13:23.49 | Ayla | we really should rewrite gmenu2x from scratch |
| 13:50.39 | *** join/#qi-hardware Ornotermes (~rikard@78-69-248-123-no180.tbcn.telia.com) |
| 13:54.26 | wpwrak | i wonder how many times gmenu2x has died in people's dreams already. everybody seems to have an assassination plan, yet it still lives on ;-) |
| 14:09.47 | *** join/#qi-hardware rejon (~rejon@jp.fabricatorz.com) |
| 14:28.23 | *** join/#qi-hardware wej (~j@95.211.13.35) |
| 15:04.02 | *** join/#qi-hardware heberth (~heberth@190.97.216.105) |
| 15:08.00 | *** join/#qi-hardware ninjak__ (~ninjak@77.239.137.142) |
| 15:24.21 | *** join/#qi-hardware emeb (~ericb@ip72-223-89-137.ph.ph.cox.net) |
| 15:32.17 | *** join/#qi-hardware rzk (~rzk@2002:2590:28d2:1:222:4dff:fe7c:450f) |
| 15:49.14 | *** join/#qi-hardware rzk (~rzk@2002:5f1c:829b:1:222:4dff:fe7c:450f) |
| 16:01.36 | *** join/#qi-hardware phirsch (~phirsch@xdsl-89-0-139-211.netcologne.de) |
| 16:03.21 | *** join/#qi-hardware rzk (~rzk@2002:5f19:4714:1:222:4dff:fe7c:450f) |
| 16:17.26 | *** join/#qi-hardware urandom__ (~user@ip-88-152-195-11.unitymediagroup.de) |
| 16:53.02 | *** join/#qi-hardware kristoffer (~kristoffe@c-5adbe555.010-30-6c6b7012.cust.bredbandsbolaget.se) |
| 17:14.21 | *** join/#qi-hardware heberth_ (~heberth@190.97.216.105) |
| 17:22.13 | *** join/#qi-hardware antgreen (~user@out-on-205.wireless.telus.com) |
| 17:40.00 | *** join/#qi-hardware Textmode (~boneidle@adsl-syd-1-124.ozonline.com.au) |
| 18:05.09 | larsc | Ayla: how crazy is this? The fan wouldn't work the whole weekend long. Took it with me to work today, hooked it up to a power supply and it worked fine. Now I took it back home and it works fine again with the laptop... |
| 18:30.59 | kristianpaul | dust dust.. |
| 19:29.12 | *** join/#qi-hardware heberth_ (~heberth@190.97.216.105) |
| 19:43.49 | *** join/#qi-hardware heberth (~heberth@190.97.216.105) |
| 19:49.10 | *** join/#qi-hardware 18VAATWMI (~heberth@190.97.216.105) |
| 20:21.12 | *** join/#qi-hardware jekhor (~jek@46.53.195.29) |
| 20:31.14 | Ayla | larsc: it just needed some fresh air ;) |
| 21:04.31 | *** join/#qi-hardware Ayla (~paul@ACaen-252-1-208-114.w86-215.abo.wanadoo.fr) |
| 21:56.59 | *** join/#qi-hardware FrankBlues (~alex@c-67-182-230-190.hsd1.ut.comcast.net) |
| 23:29.19 | *** join/#qi-hardware GNUtoo-desktop (~GNUtoo@95.232.147.72) |
| 23:30.07 | *** join/#qi-hardware DocScrutinizer05 (~HaleBopp@openmoko/engineers/joerg) |