#qi-hardware IRC log for Monday, 2012-06-25

kristianpaulwolfspraul: if you have already tested some baterry options for M1 please let us now00:28
kristianpauli'm carrying with me milkymist since tomorrow, so i'll not have power for main avaliable all times..00:29
wolfspraulnot tested00:42
kristianpauli was thinking buy 1.5V AA rechargable batteries until  get the 4.5V and see what worked :)00:45
kristianpaulwpwrak: about labsw, had you consider a cad designed case for next version? :)01:07
pabs3git rm doesn't remove non-free stuff, its still in the repo history01:48
rohwell.. duh01:58
wpwrakkristianpaul: (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:32
kristianpaulwell, i can skip MIDI not sure about USB but try avoid it02:35
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
kristianpaulwpwrak: i was thinking a 4,8V (1.2V 2100mhA x 4) battery pack02:35
wpwrakif your batteries are fresh, you'd even be within the USB spec :)02:37
qi-bot[commit] Adam Wang: qfp.fpd: added more info about QFP48 (master) http://qi-hw.com/p/kicad-libs/6c2cafe07:50
larscdoes 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
larscI see pwm signals on some of the ICs pins12:19
Aylalarsc: the mobo expects a signal from the fan12:23
Aylayou can fake it with a 55512:23
Aylaa better idea would be to change the fan if it's not working12:23
larscit is working fine, as far as i can see12:24
larscthere is just no signal on the additional pins12:24
larscAyla: do you know if it would work, if I shorted control and sense?12:39
AylaI don't think so12:40
Aylamth: I made a couple of experimental changes on gmenu2x, I'd like you to (dis-)agree with before I push anything12:42
larscAyla: you can always push it into a 'experimental' branch12:43
AylaI could do that, but I suck at GIT :p12:44
larscgit push remote localbrach:remotebranch12:44
mthis the implementation experimental or the feature itself?12:45
Aylafor the first change, I'm not sure of the implementation12:45
Aylathe 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 image12:45
Aylathat'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
Aylathe experimental features are a switch to 16bpp, and a menu clock set to... 48MHz12:47
mthgmenu2x is already slow sometimes, I prefer not to clock it down further until we resolve that slowness12:48
Ayla48MHz / 16bpp is as fast as 192MHz / 32bpp12:48
mthnot when building a file list in the explorer, I think12:49
mthalso some context menus take a long time to open12:49
Aylawhich ones?12:50
mthI forgot, but I'll make note of it when it happens again12:50
mthit happens quite often12:50
mthI do agree with wanting to render at 16bpp, although for themes that use a lot of transparency 32bpp might look better12:51
mthwhat does "reload()" do exactly?12:51
Aylamemcpy(raw->pixels, backbuffer, raw->h * raw->pitch)12:51
Aylatransparency seems to work fine12:54
AylaSDL takes care of that12:55
mthbut alpha surfaces are 32 bpp anyway and when blending, the extra precision bits on the back buffer might avoid rounding errors12:57
mthRGBA surfaces with 8-bit alpha, I mean; you can have a 16bpp surface with color keyed alpha iirc, or RGBA555112:58
Aylano, because the back buffer is not RGBA13:01
mthI mean the surface blitted onto the back buffer might be 32 bpp13:02
Aylawell, of course we lose a few bits of precision13:03
Aylabut that's expected13:03
mthanyway, we want to be able to render at 16bpp, whether we make that the default or not13:07
mthwhat is that "raw" buffer?13:08
Ayla"raw" is the name you gave to the SDL_Surface contained inside the Surface object13:08
mthwhich Surface object do you want to call it on then?13:10
mthwhat I don't understand is, why would there be an off-screen version of the current frame?13:11
mthI'd expect a repaint() rather than a reload()13:11
mthhmm, why does RGBAColor use 16 bits per component?13:13
AylaI call it on the main Surface object, the one that corresponds to the framebuffer13:17
Aylawhen using double buffering, that buffer corresponds to the one being sent to the LCD13:18
mthso the front buffer? that doesn't sound likely; SDL wouldn't give you the front buffer pointer unless you did some trickery13:19
Aylayes, I did :p13:20
AylaI save a pointer to raw->pixels on the "flip" function, before flipping the SDL_Surface13:20
mththat will break if we ever implement the rotating buffer via v4l2 idea13:20
mthI really prefer to repaint rather than save old frame contents13:21
mthrepaint should be easier than restore and if it is not, that is something that should be fixed and will improve the code overall13:21
AylaI did restore because repainting really isn't easy13:23
Aylawe really should rewrite gmenu2x from scratch13:23
wpwraki wonder how many times gmenu2x has died in people's dreams already. everybody seems to have an assassination plan, yet it still lives on ;-)13:54
larscAyla: 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:05
kristianpauldust dust..18:30
Aylalarsc: it just needed some fresh air ;)20:31
--- Tue Jun 26 201200:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!