09:37 | unicorn | Hey there |
09:38 | unicorn | Is there anyone for some help with wifi on cubox please? |
09:39 | cbxbiker61 | what's up, i'm killing some time while 6 of my computers compile code |
09:58 | unicorn | I'm trying to use the usb wifi dongle Asus N-13 on ubuntu 13.04 |
09:59 | cbxbiker61 | what chip is in the dongle? |
09:59 | unicorn | but I have the following error: rtlwifi: Firmware rtlwifi/rtl8192cufw.bin not available |
09:59 | unicorn | rtl8192cu: Chip version 0x11 |
10:00 | cbxbiker61 | should be a firmware package called something like firmware-nonfree to install |
10:03 | unicorn | I couldn't find it... |
10:05 | cbxbiker61 | get it out of the tar.gz at http://ftp.debian.org/debian/pool/non-free/f/firmware-nonfree/ |
10:06 | cbxbiker61 | 0.40 looks to be the most recent |
10:07 | wumpus | if you have another ubuntu/debian machine you can usually copy it from /lib/firmware/rtlwifi |
10:12 | unicorn | ok, I'll try those methods, thx! |
10:18 | unicorn | Copying /lib/firmware/rtlwifi seems to work! Thx a lot :) |
10:26 | shesselba | unicorn: you'll see if it is working by looking at your syslog - rtlwifi is crap, it is constantly reloading the firmware every 20 min or so *g* |
10:30 | wumpus | hehe the rtl8192cu in my gk802 doesn't even manage to connect to the access point before losing connection, but it's a driver/firmware issue, when I blacklisted the rtl8192cu there also was a "8192cu" driver in my kernel that worked better |
10:31 | wumpus | and that one didn't need firmware, pretty weird |
11:11 | dbsx | I have a working Asus N-13, give me a ninute and I will look it up |
11:15 | dbsx | On V3 kernels, the N-13 works fine with rt2800usb. Blacklist anything else that interferes. |
16:06 | dv_ | shesselba_away , _rmk_ : can I take the patches from http://lists.freedesktop.org/archives/dri-devel/2013-August/042938.html and experiment with them already? |
17:07 | shesselba | dv_: there has been an update that addresses _rmk_'s review, that on got his Tested-by http://lists.freedesktop.org/archives/dri-devel/2013-August/043764.html |
17:09 | _rmk | 17:09 * _rmk_ lols at trinity... execve(name="/sys/devices/44000000.ocp/4a056000.dma-controller/dma/dma0chan73", argv=0xb7476b20, envp=0xb7476b78) = -1 (Permission denied) |
17:24 | dv_ | shesselba: I am confused here, since I dont know much about how x11 and drm are tied together. is there also an x11 driver for this? |
17:25 | dv_ | from what I understand, this adds KMS support for dove. an x11 driver has to use that though. |
17:27 | shesselba | dv_: no, it's hdmi transmitter driver patches split-off from _rmk_'s Armada DRM driver patches |
17:31 | dv_ | oh. I see |
17:32 | dv_ | I was already wondering |
17:32 | dv_ | but I have no knowledge of the 2d hardware, so.. |
17:32 | dv_ | what I want to do is to try my vmeta stuff with _rmk_'s x11 driver, to see if the flickering disappears |
20:46 | dv_ | jnettlet: about the x11 driver: remember the vsync trick I tried? |
20:46 | dv_ | perhaps I applied it to the wrong function :) |
22:06 | jnettlet | dv_, yes, I noticed that when I was looking at it last night. |
22:07 | dv_ | tbf, the server does always send a shm completion event _immediately_ after XvdiPutImage returns, and there's no facility for doing otherwise |
22:07 | dv_ | so if your driver does anything other than copy the data out immediately (e.g. schedules a draw using that area), then it's going to be buggy |
22:09 | jnettlet | that is why we don't see the problem on the XO. I only use the textured xv driver which uses the 2d graphics engine to blit the decoded frames to the framebuffer |
22:11 | jnettle | 22:11 * jnettlet has to go afk. have some things to chat with you about tomorrow. ttyl |
22:12 | dv_ | alright. ttyl |