| qi-bot | The Openwrt build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-openwrt.minimal-09152011-0240/ | 01:35 |
|---|---|---|
| cde | hi there | 01:40 |
| wolfspraul | cde: hi! | 01:40 |
| wolfspraul | so.. | 01:40 |
| wolfspraul | so basically say nothing works, right? | 01:40 |
| wolfspraul | your jtag-serial board doesn't show up at all over usb, your m1 doesn't boot | 01:41 |
| wolfspraul | at least we start from a place where things can only improve :-) | 01:41 |
| cde | well leds blink, so that's at least something ;) | 01:41 |
| wolfspraul | but what now? I don't know | 01:41 |
| wolfspraul | the unit was 100% tested before shipping out, very extensively actually | 01:41 |
| wolfspraul | but now, hmm, don't know | 01:41 |
| cde | yes, I believe you | 01:42 |
| wolfspraul | leds blink is not enough | 01:42 |
| wolfspraul | why does the jtag-serial not register over usb? | 01:42 |
| wolfspraul | totally nothing coming in over usb? | 01:42 |
| wolfspraul | how is that possible | 01:42 |
| cde | I dont think it was damaged in transit | 01:42 |
| wolfspraul | we never had that, ever | 01:42 |
| cde | nope, nothing :( | 01:42 |
| wolfspraul | the USB power works I guess (led on jtag-serial comes on?), but the ftdi chip doesn't start sending stuff over usb? | 01:42 |
| GitHub163 | [scripts] xiangfu pushed 1 new commit to master: http://git.io/K633PA | 01:43 |
| GitHub163 | [scripts/master] scripts: ignore build when no new commit - Xiangfu Liu | 01:43 |
| cde | well Linux detects no device at all | 01:43 |
| wolfspraul | _anything_ in dmesg? | 01:43 |
| cde | nothing | 01:43 |
| wolfspraul | I'm at a loss | 01:43 |
| wolfspraul | we never had a case like this | 01:44 |
| wolfspraul | since the first prototype of the jtag-serial boards | 01:44 |
| cde | I'm thinking ESD | 01:44 |
| wolfspraul | well | 01:44 |
| wolfspraul | your m1 seems also dead? | 01:44 |
| cde | possibly, but I really have no tools to diagnose it | 01:44 |
| xiangfu | cde, 1. replug the jtag-serial to your pc. 2. check 'dmesg' | 01:45 |
| wolfspraul | something pretty drastic must have happened somewhere | 01:45 |
| wolfspraul | xiangfu: nah, he checked a lot already | 01:45 |
| xiangfu | oh. | 01:45 |
| cde | xiangfu: I did that countless times | 01:45 |
| wolfspraul | when you power-on your m1, which LED of the three leds on m1 comes on? | 01:45 |
| wolfspraul | I mean when you plug in the power supply | 01:45 |
| cde | the one on the most left iirc | 01:46 |
| wolfspraul | watch out to only plug the 5V supply into m1 :-) | 01:46 |
| wolfspraul | is it possible that you plugged in the 12V supply at some point? | 01:46 |
| xiangfu | cde, left? | 01:46 |
| wolfspraul | there is protection against that, but just curious/asking | 01:46 |
| wolfspraul | cde: ok, and then when you press the middle button, what happens? | 01:46 |
| wolfspraul | xiangfu: after m1 boots, what is the ethernet IP of m1 ? | 01:46 |
| cde | nope, was vey careful to use the M1 brick | 01:46 |
| wolfspraul | no worries it has protection against accidentally plugging in 12V, though you shouldn't try that just for fun... | 01:47 |
| cde | hmm, iirc middle led turns on | 01:47 |
| wolfspraul | and then after 30-40 seconds the third one comes on? | 01:47 |
| cde | then after awhile right led | 01:47 |
| xiangfu | wolfspraul, it try to get from DHCP | 01:47 |
| wolfspraul | ok | 01:47 |
| wolfspraul | cde: but nothing on vga? | 01:47 |
| cde | nope | 01:47 |
| wolfspraul | what do you connect the vga to? | 01:48 |
| cde | unless the tv somehow didn't see the signal | 01:48 |
| wolfspraul | tv? | 01:48 |
| wolfspraul | the tv has a vga in? | 01:48 |
| wolfspraul | yes that is (remotely) possible | 01:48 |
| wolfspraul | I've heard a story before (from kristianpaul) who said he plugged m1 into something (vga) but it didn't work (on that particular projector or whatever it was) | 01:49 |
| cde | yep my brother uses it to plug in an media center | 01:49 |
| wolfspraul | xiangfu: if dhcp fails, what's the fallback IP? | 01:49 |
| wolfspraul | cde: and that worked? | 01:49 |
| xiangfu | wolfspraul, then no IP address | 01:49 |
| wolfspraul | that was in France? | 01:49 |
| wolfspraul | xiangfu: it should fall back to a fixed ip | 01:49 |
| wolfspraul | for diagnostics | 01:49 |
| wolfspraul | otherwise for example cde cannot just connect it to his hotebook now to try to log on. or can he? | 01:50 |
| cde | well to be franck I didn't test my m! until today | 01:50 |
| cde | (my brother lives in NY) | 01:50 |
| wolfspraul | I can tell | 01:50 |
| wolfspraul | but last minute is most fun :-) | 01:50 |
| wolfspraul | no? | 01:50 |
| wolfspraul | last minute is when we get all the important things done, and make the important realizations (like no static IP fallback, he he :-)) | 01:51 |
| cde | well it must be disappointing for lekernel | 01:51 |
| wolfspraul | cde: so you saw the vga output working? | 01:51 |
| wolfspraul | why disappointing? | 01:51 |
| wolfspraul | and what? | 01:51 |
| cde | no | 01:51 |
| wolfspraul | you just wrote 'my brother uses it to plug in an media center' - I don't understand | 01:51 |
| cde | well since I had to do a working demo :) | 01:51 |
| wolfspraul | if the TV doesn't pickup the signal, first we should try one other monitor or projector | 01:52 |
| cde | however let me just try the M! on another screen | 01:52 |
| wolfspraul | did you have the demo already? | 01:52 |
| wolfspraul | or you say the demo failed because m1 didn't work? | 01:52 |
| cde | it's happening tomorrow at the OHS | 01:52 |
| wolfspraul | ok do you have another screen to test vga now? | 01:53 |
| wolfspraul | I guess you cannot log in over Ethernet unless you find something that responds to DHCP | 01:53 |
| wolfspraul | xiangfu: ? | 01:53 |
| wolfspraul | how can he do that? | 01:53 |
| wolfspraul | from the LED action, it looks like m1 is booting | 01:53 |
| cde | sure 10mn | 01:54 |
| wolfspraul | at least that :-) | 01:54 |
| wolfspraul | so: | 01:54 |
| wolfspraul | 1) jtag-serial seems 'dead', quite strange | 01:54 |
| xiangfu | wolfspraul, (DHCP) that is true. | 01:54 |
| wolfspraul | 2) Ethernet is inaccessible because no static IP fallback and no DHCP partner available right now | 01:55 |
| wolfspraul | 3) vga-out does not work with the TV, looking for another screen | 01:55 |
| xiangfu | cde, we can try to reflash your jtag-serial, only if you make sure it is dead for now | 01:55 |
| cde | hmm wait this network has dhcp | 01:55 |
| wolfspraul | but then how do you know the address? | 01:55 |
| cde | oh I can nmap the range | 01:56 |
| xiangfu | cde, even m1 have success get ip address, you have to setup the Username and Password under Flickernoise. | 01:56 |
| wolfspraul | :-) | 01:56 |
| cde | brb | 01:56 |
| xiangfu | which mean the VGA have to works. | 01:56 |
| wolfspraul | xiangfu: please think about a way to get access over ethernet without vga or keyboard | 01:56 |
| xiangfu | cde, there are FTP and Telnet service in m1. | 01:56 |
| wolfspraul | there should be a static IP fallback, that's easy | 01:57 |
| wolfspraul | and there should be some way to setup username/password over ethernet? we need to think about it | 01:57 |
| wolfspraul | xiangfu: reflash jtag-serial is a good idea, but how? is it easy for cde now? | 01:57 |
| wolfspraul | I doubt this will help though, something bad must have happened | 01:57 |
| wolfspraul | reflash will only touch the eeprom with some config data, but his jtag-serial seems totally dead, like the ftdi chip not doing anything | 01:58 |
| xiangfu | cde, which release you using? | 02:01 |
| xiangfu | cde, have you ever reflash your m1 ? | 02:02 |
| xiangfu | cde, the old image have static ip address. 192.168.0.42 | 02:02 |
| cde | so vga just worked! | 02:03 |
| cde | it was indeed the tv, I think the M! | 02:03 |
| cde | 1 is fine | 02:03 |
| wolfspraul | xiangfu: he just received a brand new rc3 | 02:04 |
| wolfspraul | ok, m1 works. that's good. | 02:04 |
| wolfspraul | jtag-serial, hmm | 02:04 |
| cde | about the ftdi, it's not a big deal I has a couple at home that I don't use | 02:04 |
| wolfspraul | well | 02:04 |
| xiangfu | cde, m1 is stable :-) | 02:04 |
| wolfspraul | cde: I will mail you a replacement, free of course | 02:04 |
| wolfspraul | but that's not in time for the ohs | 02:05 |
| wolfspraul | as for returning the one you have, it's probably not worth it | 02:05 |
| cde | np, at least the demo is showing | 02:05 |
| wolfspraul | you can do a bit more investigation yourself if you like, that would tremendously help our project | 02:05 |
| wolfspraul | you are at least as good or better than the people and resources we have, expect no magic on my end :-) | 02:05 |
| cde | hmm with my 10mhz scope I might not be of much help ;) | 02:05 |
| xiangfu | those two wiki pages will help on reflash jtag-serial: http://www.milkymist.org/wiki/index.php?title=Build_the_libftdi-1.0_and_new_ftdi_eeprom and http://www.milkymist.org/wiki/index.php?title=Working_ftdi_eeprom | 02:05 |
| wolfspraul | it's up to you of course. most likely if you return it though, it will just be discarded because I don't have enough resources to do a deep analysis. | 02:06 |
| wolfspraul | it is a strange finding though, totally no response | 02:06 |
| wolfspraul | let's see what others say later | 02:06 |
| wolfspraul | xiangfu: I cannot imagine that reflashing the eeprom on jtag-serial helps at all | 02:06 |
| wolfspraul | the ftdi chip is not doing anything it seems | 02:06 |
| wolfspraul | cde can try to short the eeprom to rule it out as a source of the problem | 02:07 |
| cde | sure, i'll return it just in case so you can have a look | 02:07 |
| wolfspraul | no need | 02:07 |
| wolfspraul | I have no resources | 02:07 |
| wolfspraul | so you just waste time and money returning it | 02:07 |
| xiangfu | wolfspraul, seems ftdi chip totally dead. | 02:07 |
| wolfspraul | cde could try to short the eeprom | 02:07 |
| cde | ok I'll try flashing the eeprom | 02:07 |
| wolfspraul | sure you can try :-) | 02:07 |
| wolfspraul | thanks! | 02:07 |
| wolfspraul | shorting the eeprom also, I just forgot how to do it | 02:07 |
| wolfspraul | searching backlog... | 02:07 |
| wolfspraul | you just have to short something on the little thing | 02:08 |
| wolfspraul | please keep it disconnected from m1 for now | 02:08 |
| xiangfu | put the pin 1 of the eeprom to the ground | 02:08 |
| wolfspraul | ah | 02:08 |
| wolfspraul | xiangfu: thanks! | 02:08 |
| wolfspraul | cde: so you can try that. pin 1 of eeprom to ground, then connect usb | 02:08 |
| wolfspraul | but please DISCONNECTED from m1 | 02:08 |
| cde | yeah got it :) | 02:08 |
| xiangfu | http://www.milkymist.org/wiki/index.php?title=Working_ftdi_eeprom#Caution_.28RESET.29 | 02:09 |
| wolfspraul | maybe someone at ohs has a usb protocol analyzer | 02:09 |
| wolfspraul | you could see whether anything goes over the wire | 02:09 |
| wolfspraul | at some point there is nothing but the ftdi chip in the way. if you indeed have the same one and can rework it - go ahead just for fun to see whether you can fix it :-) | 02:10 |
| wolfspraul | but it's a qfn I think, right? a bit hard to rework | 02:10 |
| wolfspraul | I'll send you a new daughterboard for sure (unless it somehow comes back to life now) | 02:10 |
| cde | yeah I'll ask around at ohs! thanks very much guys for the help | 02:10 |
| wolfspraul | wait, try short eeprom | 02:11 |
| wolfspraul | I'm curious | 02:11 |
| wolfspraul | we never had a case like this, want to understand | 02:11 |
| wolfspraul | it's a simple board | 02:11 |
| wolfspraul | power comes on - why is the ftdi chip unresponsive? | 02:11 |
| wolfspraul | and what happened after shipping it out? total mystery to me... | 02:11 |
| cde | ah don't have the equipment here :) will try it when back in france | 02:11 |
| wolfspraul | esd? looks like an easy excuse | 02:11 |
| wolfspraul | can you short the eeprom now to try? | 02:12 |
| wolfspraul | for the m1 demo, you can iterate over the patches by pressing the right button I think (or the left one) | 02:12 |
| wolfspraul | that will switch to the next patch | 02:12 |
| wolfspraul | some patches use the camera, so you may want to connect the camera as well | 02:12 |
| cde | ah good to know thanks :) | 02:13 |
| xiangfu | left -- for previous patch, right -- for next patch | 02:13 |
| cde | I need to go to sleep now (have to wake up early) I'll let you know how it goes! | 02:14 |
| wolfspraul | yes, you absolutely need a line-in music input | 02:14 |
| wolfspraul | otherwise no point in m1 | 02:14 |
| wolfspraul | that's the #1 | 02:14 |
| wolfspraul | then the second one is the camera, real-time video synthesis | 02:14 |
| wolfspraul | sure, go sleep | 02:15 |
| wolfspraul | let us know how it went | 02:15 |
| wolfspraul | we'll fix the jtag-serial issue too, no worries... | 02:15 |
| wolfspraul | cde: thanks for the feedback! | 02:15 |
| xiangfu | cde, good night | 02:16 |
| wolfspraul | oh | 02:19 |
| wolfspraul | and of course, we should also find out one day why the TV didn't pick up the signal | 02:19 |
| wolfspraul | there is probably something that can still be improved on m1, if the tv accepts a vga input that should work... | 02:19 |
| wolfspraul | cde: which tv model is this? just the brand... | 02:19 |
| roh | wolfspraul: there is no too hard in rework. only too bad yield ;) | 02:35 |
| qi-bot | The Firmware build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-09152011-0336/ | 03:12 |
| kristianpaul | for the tv i had problem with my theory was that some resolution may no be supported, also at that time my laptop dint worked either :/ | 04:59 |
| wpwrak | kristianpaul: never abandon a good theory just because it's wrong ;-) | 04:59 |
| kristianpaul | :) | 05:00 |
| kristianpaul | also at that time my m1 want able to do higher resolution for gui | 05:02 |
| kristianpaul | and i dont bother in take tc specs as it came froma local company that asseble tv's and other home appliaces | 05:02 |
| kristianpaul | s/tc/tv | 05:02 |
| wpwrak | ah yes, that brand name inflation game. as if there weren't enough brands already in china ... | 05:04 |
| kristianpaul | s/want/wasnt | 05:06 |
| qi-bot | The Openwrt build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-openwrt.minimal-09152011-0611/ | 05:06 |
| kristianpaul | and after i upgrade the firmware for that date, i again have problems when coming from gui to render with a vide proyector.. oh well.. | 05:07 |
| kristianpaul | but was a baracamp so again i had no time to take specs .. and i also have to run for a workshop | 05:07 |
| qi-bot | The Firmware build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-09152011-0706/ | 06:42 |
| wpwrak | joy ! finally got a standby corruption. took only some 32-34 hours. and they seem to come in clusters. | 07:01 |
| wpwrak | xiangfu: does the CRC check in the test software start at the first word (0xffff ...) or at some offset ? | 07:02 |
| xiangfu | no offset. | 07:03 |
| xiangfu | start at 0x00000000 in nor flash. | 07:05 |
| wpwrak | grmbl. so NOR corruptions do indeed come in clusters. i see a lot in the first few words, plus always one deeper inside | 07:05 |
| xiangfu | wpwrak, what is that mean of 'come in clusters' ? | 07:08 |
| wpwrak | btw, where is the source of the test software ? (that boot.4e53273.bin) i don't see it in git://github.com/milkymist/milkymist | 07:08 |
| xiangfu | git://github.com/milkymist/autotest-m1 | 07:08 |
| wpwrak | (clusters) seems that more than one NOR corruption happens within a short time span. maybe even within the same cycle. | 07:09 |
| wpwrak | thanks ! | 07:09 |
| xiangfu | the https://github.com/milkymist is a group. all milkymist stuff is under 'https://github.com/milkymist' | 07:10 |
| xiangfu | wpwrak, (clusters) ok. got it thanks. | 07:10 |
| wpwrak | (group) oh, nice. thanks ! | 07:12 |
| wpwrak | let's see if these clusters may be related to temperature. i seem to get a bit more corruption in the middle of the night. | 07:15 |
| wpwrak | or maybe it's the effect of moonlight ... | 07:16 |
| xiangfu | wolfbug :) | 07:19 |
| wpwrak | ;-)) | 07:20 |
| wpwrak | werebug :) | 07:20 |
| xiangfu | oh. yes | 07:20 |
| xiangfu | wpwrak, if it related to temperature. we will have big problem in winter, just the next few month | 07:22 |
| wpwrak | indeed :) and i have to hurry, because i only have a few weeks left to reproduce the bug. well, unless i relocate my m1 to the fridge :) | 07:26 |
| lekernel | re. those screen detection problems, perhaps I should use the exact 25.175MHz pixel clock instead of 25MHz | 07:47 |
| lekernel | I thought all screens were able to tolerate this (and read the same in many places), but apparently not | 07:47 |
| wpwrak | i would expect at lest that much tolerance too | 07:48 |
| wpwrak | maybe it's something else ? e.g., sync polarity or such ? | 07:48 |
| lekernel | I had a similar issue on another beamer - detecting some very high resolution like 2048x1024 and displaying only a distorted portion of the 640x480 picture | 07:49 |
| lekernel | it rather looks like a video timing problem | 07:49 |
| lekernel | did cde try with another USB cable btw? | 07:51 |
| wpwrak | maybe the sync pulses have the wrong timing ? and yes, vga timing is interesting. changes quite a lot between resolutions. and polarities do, too | 07:51 |
| lekernel | it's only using negative polarity | 07:52 |
| wolfspraul | he said he tried several cables yes | 07:54 |
| wolfspraul | for the tv problem, it could also simply be that the vga-in of that tv is broken, or that a certain channel had to be selected manually | 07:54 |
| wolfspraul | but of course, if we can improve something on the m1 side, even better. | 07:54 |
| wolfspraul | I hope his demo goes fine, a little strange with the dead jtag-serial board. | 07:55 |
| wpwrak | ((tag board) yeah, the kernel should say something | 07:57 |
| wpwrak | for 640x480, negative hsync/vsync would indeed be correct | 07:59 |
| wolfspraul | but the kernel says nothing, and since the board appears powered (led on), it can only be a plain failure of the ftdi chip | 08:00 |
| wolfspraul | eeprom shorting still to be done | 08:00 |
| wolfspraul | i'm wondering what triggered this, since it definitely worked just a few days ago before shipping | 08:01 |
| wolfspraul | oh well | 08:01 |
| wolfspraul | hardware is hard | 08:01 |
| wpwrak | i kinda wonder ... i would expect the kernel to at least announce that it found a low/full-speed device | 08:01 |
| wolfspraul | nothing | 08:01 |
| wolfspraul | not a single line in dmesg | 08:01 |
| wpwrak | maybe the usb connector came a little loose | 08:01 |
| wolfspraul | well, let's see | 08:01 |
| wolfspraul | we have to wait | 08:01 |
| wolfspraul | good idea [push down usb connector] | 08:02 |
| wpwrak | (which could also be on the pc side. particularly those ether-double-usb combos are more than fragile) | 08:02 |
| wpwrak | (dmesg) a good test would be to connect a known to be good device, paste the dmesh. then remove the device and connect the jtag on that very same port. paste dmesg again. | 08:03 |
| qi-bot | The Openwrt build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-openwrt.minimal-09152011-0941/ | 08:36 |
| GitHub168 | [scripts] xiangfu force-pushed master from 2b3a2d9 to 282c36d: http://git.io/DOsw5Q | 08:40 |
| GitHub168 | [scripts/master] scripts: ignore build when no new commit - Xiangfu Liu | 08:40 |
| lekernel | if there's a open or short circuit on one of the USB data lines (which can come from a fault cable or connector), it will produce this symptom | 08:45 |
| wolfspraul | sounds exotic | 08:45 |
| wolfspraul | he will test some more when he's back in france, I hope | 08:46 |
| qi-bot | The Firmware build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-09152011-1036/ | 10:12 |
| wpwrak | hmmm ... i think it should be fun to profile this compiler | 11:42 |
| kristianpaul | what this? | 11:48 |
| wpwrak | compiler.c may spend quite some time doing string operations. that may explain some of the slowness. the things it calls look better at a first glance, though. profiling should show if the inefficiency of compiler.c really has a significant impact on overall performance or not. | 11:51 |
| larsc | compiler.c? | 11:53 |
| kristianpaul | flickernoise i guess | 11:54 |
| kristianpaul | at least wpwrak mean llhdl perhaps? | 11:54 |
| kristianpaul | :) | 11:54 |
| wpwrak | flikcernoise/src/compiler.c | 11:55 |
| wpwrak | things like pfv_from_name | 11:56 |
| wpwrak | milkymist/software/libfpvm/ uses re2c and lemon. i don't know them, but they're probably reasonably efficient (i mean, why else depart from lex and yacc) | 11:59 |
| wpwrak | well, maybe ... i still see a lot of copying | 12:07 |
| lekernel | wpwrak, because parsers generated by lex and yacc only work on GNU systems ... | 12:07 |
| lekernel | wpwrak, C programming is about copying :) | 12:08 |
| lekernel | (if I understand "copying" as "code duplication and reinventing the wheel" ...) | 12:08 |
| larsc | damm! and i always though it was about reuse | 12:09 |
| wpwrak | you must mean flex and bison. lex and yacc must have been considered old before rms was even born ;) | 12:09 |
| wpwrak | (duplicate) you must have spent too much time in china ;-) | 12:10 |
| wpwrak | of course, unix-style reuse is often in the form of new_interface | old_engine ;-) | 12:17 |
| larsc | "and every year we decided to add a new layer to hide the crap we've down the year before" | 12:18 |
| wpwrak | until the day comes when the archeologists roll up their sleeves and go spelunking :) | 12:22 |
| qi-bot | The Firmware build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-09152011-1312/ | 12:48 |
| mwalle | wpwrak: have you tried cooler spray and a hot air gun? | 20:38 |
| GitHub169 | [scripts] sbourdeauducq pushed 3 new commits to master: http://git.io/_Zt8Kg | 20:45 |
| GitHub169 | [scripts/master] Update makefile to use rtems cvs repository instead of deleted milkymist git clone. - JP Bonn | 20:45 |
| GitHub169 | [scripts/master] Updated for latest build script and rtems cvs tree. - JP Bonn | 20:45 |
| GitHub169 | [scripts/master] Merge pull request #2 from jpbonn/master - Sébastien Bourdeauducq | 20:45 |
| mwalle | lekernel: what is tmu early ack? | 20:47 |
| lekernel | an experiment that lets the SDRAM controller acknowledge the transfer a fixed number of cycles before the data gets actually transferred, to allow for more request pipelining efficiency | 20:49 |
| lekernel | it doesn't make any difference from the LM32 point of view | 20:51 |
| lekernel | it's just a tad bit faster | 20:51 |
| mwalle | mh qemu head is broken (at least for lm32?) | 21:29 |
| mwalle | lekernel: i guess that experiment is just for fun? or do you want to squeeze the last bit performance out of the soc already? :) | 21:40 |
| mwalle | lekernel: are u still using tiling windowmanages? | 21:48 |
| wpwrak | (early ack) i guess that's for trying to get things to work at higher resolutions | 22:04 |
| wpwrak | (cold/hot air) hmm, so far, i'm not desperate enough for that :) | 22:05 |
| --- Fri Sep 16 2011 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!