deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
hipboi has joined #linux-sunxi
<xDR1TeK>
hi again, i think i have a problem with uberizer as it is not taking the dump files and flashing the tablet back again
<xDR1TeK>
keeps telling me not enough space when i copy /sdcard/recovery_install to /emmc/recovery_install/
<xDR1TeK>
when i go back to clockwork, uberizer asks to format some folders and then mount them
<xDR1TeK>
but when i click to continue
<xDR1TeK>
it cant find the files in emmc and that is why i am copying them by hand
<xDR1TeK>
so when i did copy the recovery_install to emmc and managed to make uberizer to resume, still the tablet won't boot
<xDR1TeK>
this is crazy
<xDR1TeK>
without fastboot i cant flash boot.img
<xDR1TeK>
i made my changes to system, bootloader and boot
<xDR1TeK>
but cant flash those back
<xDR1TeK>
unless i serially flash the rom image, i can't boot my tablet
jdeisenberg has joined #linux-sunxi
<xDR1TeK>
and i don't know how to merge the boot, bootloader, system, data and recovery back to one rom
<jdeisenberg>
Hi. Have a Mele M%; when in android mode, I have to deliberately select ethernet for the box to recognize the connection. When I boot Fedora 19, I see "connected" for about 1 second, then "disconnected" again.
<jdeisenberg>
I suspect I need some way to explicitly force it to look at ethernet; any ideas?
<jdeisenberg>
btw, hipboi, thanks for the hint about using the cubieboard boot stuff; that worked great.
<hipboi>
jdeisenberg, good to hear
<jdeisenberg>
Hm. Go figure. It wasn't working at the school, but it's working here at home.
<jdeisenberg>
I spoke too soon. Just got disconnected again.
<xDR1TeK>
can i do this: cat /sdcard/recovery_install/boot.img /dev/block/nandc
xDR1TeK has quit [Quit: SleEeEeEp]
akaizen has quit [Remote host closed the connection]
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
jdeisenberg has left #linux-sunxi [#linux-sunxi]
JohnDoe_71Rus has joined #linux-sunxi
Black_Horseman has quit [Remote host closed the connection]
kaspter has joined #linux-sunxi
bamvor has joined #linux-sunxi
bamvor has quit [Remote host closed the connection]
rz2k has joined #linux-sunxi
stulluk has joined #linux-sunxi
stulluk has quit [Ping timeout: 248 seconds]
<oliv3r>
mornin' ya'll
<andoma>
oi
<wens>
i see the dts for A20 in mainline is minimal. Is anyone working on it?
<wens>
considering the work is just translating the specs to dts, I'd like to give it a shot.
<oliv3r>
wens: its intended
<oliv3r>
first you write a driver, then you write only that section for the dts
<oliv3r>
we dont' put everything in the dts, but then miss the driver for it
<wens>
oliv3r: i see
akaizen has joined #linux-sunxi
kaspter has quit [Ping timeout: 260 seconds]
panda84kde has joined #linux-sunxi
BluesBoy has joined #linux-sunxi
n01 has joined #linux-sunxi
rellla has joined #linux-sunxi
<oliv3r>
mripard: You said 'make that an inline function' but i remember reading to never mark anything inline, as the compiler knows when to inline something better then you (you the person, not you personally). There's of course always exceptions
<wens>
arokux: i have zero experience, but i do want to do something to get my cubieboard2 running mainline
<buZz>
eh
<arokux>
wens, I see. me too, I'm struggling to add usb support. now I have 200 lines of code that works in sunxi-3.4 but does not work in mainline sooner or later I'll find the reason :)
<wens>
i haven't got mainline to run on it yet, no console. probably bad config on my part.
<arokux>
wens, also I recommend to set up booting over NFS if you want to hack on the kernel, this will speed up reboot cycles. burning of sd card is way slower
<arokux>
mnemoc, couldn't you just remove my commit instead of adding another commit that reverts it?
<mnemoc>
arokux: if I just remove it, people rebasing will put it back
<mnemoc>
stage was merged, except your commit and it's revert. for temporal rebase friendliness
<mnemoc>
if there is nothing critical pending, I can tag -r2 and jump to the next android-3.4+v3.4.y
<mnemoc>
is there anything critical pending in sunxi-3.4?
<oliv3r>
arokux: gcc says 'leave inline to the compiler to decide it for you, don't explicitly mark it unless absolutly required'
<arokux>
oliv3r, you can still mark func inline, then gcc will decide when to inline them. this decision will be for example based on --optimize=speed or --optimize=size
<arokux>
oliv3r, kernel folks just want ultimate control it is understandable and i have nothing against it, but to claim gcc is _broken_ is simply arrogant, but well, this is Linus' style of talking
<arokux>
JohnDoe_71Rus, ah, ok, no, I was talking about gmane, some e-mails are missing there.
<arokux>
ah.. I figured out something. if some older thread was replied the reply gets appended to the thread, which however is somewhere at the bottom since everything is sorted by the date of the first message in thread...
Black_Horseman has joined #linux-sunxi
Black_Horseman has joined #linux-sunxi
<wens>
just realized emac isn't supported on a20 yet
<wens>
been banging my head against the wall for the past hour
<arokux>
wens, oh really?
<wens>
arokux: yeah, a20 only has basic support, like clocks, irqs, uarts
<arokux>
wens, maybe this will be your first task. emac is really needed.
* wens
takes out spec sheet
Black_Horseman has quit [Quit: Zwi se logou mou!!!]
<jemk>
ssvb: i don't think so (at least for rgb layers)
<ssvb>
jemk: well, then go for it :)
<jemk>
ssvb: i don't understand how i could add that without breaking existing software. how should this version thing in disp work?
<jemk>
and i don't know how i should test it with other layer types, as i don't know of software using that
<ssvb>
afaik there is not much software using layers
<jemk>
this hasn't to do anything with layers, thats only using scaler (to convert tiled yuv to rgb buffer)
<ssvb>
I mean you can't break too many relevant applications no matter what you do there, just try to make a prototype that does the right thing for you and we can see how to integrate it in the least invasive way
<jemk>
ssvb: prototype exists, but very ugly and only fits for rgb (4byte per pixel)
<oliv3r>
arokux: my hero :)
<arokux>
oliv3r, not really, just want to get rid of my Mele A1000
<oliv3r>
arokux: replace it with m5?
<arokux>
oliv3r, yes, bad idea?
<oliv3r>
arokux: i want an m5 :p
<oliv3r>
but with a23 ;)
<oliv3r>
so i'll be patient :D
<oliv3r>
i bet it'll be same pcb if they bring it out at all
<arokux>
oliv3r, how is it better?
<oliv3r>
but i was hopign you allready gotten the pics
<oliv3r>
arokux: it's higher clocked; i hope the memory controller is better/faster
<libv>
jemk: this version thing is supposed to give users of disp the ability to detect when the api/abi changes
<arokux>
oliv3r, hm.. but not fast enough to be noticeable, or?
atiti has joined #linux-sunxi
<wens>
arokux: got it sending DHCP for now
<arokux>
wens, with kernel or u-boot?
<libv>
jemk: it's been 10 or so months since i introduced it, but i think no-one so far has bumped it
<wens>
I noticed that the interrupts for a20 actually follow a10, and not the a20 spec. and changing them to follow the spec results in the system not working
<libv>
jemk: if you are just adding stuff, bump the lower value, if you are making fundamental changes, bump the upper
<wens>
maybe has something to do with SMP not working yet
<wens>
arokux: kernel
<jemk>
ssvb: http://sprunge.us/HONa?diff but that was only a short test to get an idea if it will work (it does for rgb)
<jemk>
libv: well, adding a parameter will be a change in api, if someone doesn't fill this parameter strange things happen
<libv>
jemk: so you are changing existing ioctls
<libv>
jemk: then bump the major number
<libv>
jemk: we have 16 bits of major number, so don't be afraid to use it
<ssvb>
or just add a new ioctls to support new features
<libv>
i do hope that either sunxi is dead, or disp gets replaced properly, by the time we run into the limit :)
<libv>
at the current rate, i think we're pretty safe
<jemk>
well, new ioctl could happen anyways, cause later i think we need deinterlacing
<jemk>
scaler can do many things, but noone realy uses them
<arokux>
oliv3r, any Mele employees around here? I've seen Mele contacted arm-netbook and offered cheap devices
<ssvb>
jemk: the use of the writeback feature and then mixer processor is pretty obvious for vdpau, the things seem to be progressing nicely :)
<jemk>
ssvb: thats what im trying, but it means giving up zero copy
<ssvb>
jemk: maybe this still could be optimized, because the subtitles and osd don't usually take much of the screen space
<ssvb>
jemk: for example, use one layer for the whole video, and then another smaller one covering only the part, which participates in extra compositing
leviathanch has quit [Read error: Connection reset by peer]
<jemk>
ssvb: you mean disp layers?
<ssvb>
yes
<jemk>
as far as i understand manuals only 2 overlaping layers are possible, and desktop already uses one
hansg has joined #linux-sunxi
leviathanch has joined #linux-sunxi
<ssvb>
hmm, is it so?
<ssvb>
the colorkey sure has some restrictions, but I thought that the opaque layers might be more flexible
* ssvb
needs to check the manuals again
<jemk>
to be precise, only two layers can be used as input, so if we need colorkey for window masking it wont work
<ssvb>
well, I'm not a big fan of colorkey and we can do without it
<ssvb>
colorkey steals more memory bandwidth when it is enabled, which is not very nice
<jemk>
but how to do then?
<ssvb>
if the window is fully visible, we don't need to use colorkey
<ssvb>
if the window is partially overlapped, then the fallback path can be taken with extra copies
<ssvb>
that's how I'm implementing dri2 at the moment
<ssvb>
as for the layers, the documentation seems to say that there are two pipes which go the the alpha blender/colorkey
<arokux>
correct me if I'm wrong. from what I read allwinner has got community attention whereas rockchip has better SoCs..
<oliv3r>
arokux: not that i know off
<jemk>
ssvb: can dri be used already? if yes, is there any documentation how to do so?
<ssvb>
jemk: each pipe can have multiple layers assigned to it, and the rule is "If more than 1 layers select the same pipe, in the overlapping area, only the pixel of highest priority layer can pass the pipe to blender1"
<jemk>
yes, thats what i ment
<ssvb>
jemk: so supposedly we may have all 4 layers composited together, but only a single blender for handling the colorkey
<jemk>
if layers use same pipe only the one with higher priority is used, so color key and three layers will fail
<ssvb>
how so? we can have one pipe with just the desktop layer
<ssvb>
and another pipe with all the vdpau layers
<jemk>
ah, you mean copy the video in a small part of an extra layer and set this on top of the video layer?
<ssvb>
yes, though only practice will show if it is going to be workable
<jemk>
that could be hard to implement, as long as only one extra layer is needed like subtitle its ok, but if some player uses many layers it'll be fun
<ssvb>
yes, but that's just a possible simple optimization, and we only care whether it is usable in most practical cases
<ssvb>
the remaining cases can take a slow path
<jemk>
i will think about this way, that would also render the kernel change unnecessary
<jemk>
but one problem still remains. downscaling a big layer (e.g. 1080p video in small window) doesn't work
vinifr has quit [Quit: Saindo]
<oliv3r>
arokux: we dont' know, onyl saw the announcement for a23 so far
<ssvb>
what are the limits for downscaling?
<jemk>
there seem to be some bandwidth issue, scaling to a writeback buffer it works, live it does not
hansg has quit [Quit: Leaving]
<oliv3r>
wens: can you show me what you've done so far? It's extrmely unlikley the core itself has changed for emac, since they added gmac for gbit (and possible mbit)
<arokux>
oliv3r, he got dhcp working from the kernel
<ssvb>
jemk: ok, maybe a bit of investigation is needed for that
<wens>
oliv3r: I just copied the emac and mdio sections from sun4i-a10.dtsi to sun7i-a20.dtsi
<arokux>
wens, ethernet works fine now?
<ssvb>
jemk: as for the dri2, we just might need to hack in an extra communication channel to pass the extra information
<jemk>
ssvb: somewhere around 1/3, but only if width is big. thats why i thought disp can't get the data as fast as needed for display scanout
<wens>
arokux: it's not now. stuck after libphy: sun4i_mii_bus: probed
<ssvb>
jemk: so that with DRI2 you send the DRI2SwapBuffers request, but then the DDX driver uses a custom ioctl to fetch additional information about the buffer address and the other things
<arokux>
wens, but you said dhcp is working?
<wens>
arokux: yeah, I got nfs root up and running nicely. after a reboot and it breaks down...
<oliv3r>
arokux: that not that i know off was your first comment towards me :p as for rockchip, sounds reasonable, but RK has much worse linux support
<arokux>
wens, mm.. so it worked and now it doesn't?
<wens>
arokux: correct.
<arokux>
wens, ok, so find out what you've broken :)
<wens>
arokux: hopefully not the board :p
<arokux>
wens, to test it boot sunxi-3.4 :) that is what I do. set up your u-boot so that you can easily boot either mainline or sunxi-3.4. I use env variables for that.
<ssvb>
jemk: for this 1080p downscaling problem, have you tried experimenting with different memory clock speed to see whether it affects the practically usable maximum downscaling ratio?
<wens>
arokux: just tested a clean build, and it's working again.
<arokux>
and then just "run ml" boots mainline for me, run aw boots sunxi-3.4
ynezz has quit [Ping timeout: 264 seconds]
<wens>
arokux: but i broke my nfs root for no apparent reason :(
tinti has joined #linux-sunxi
<wens>
arokux: will continue tomorrow
<arokux>
wens, ok, good luck
<oliv3r>
wens: that won't work exactly; you need to use the a20 IRQ (address probably is the samee)
<oliv3r>
wens: dhcp works because u-boot probably still works with emac, i guess u-boot doesn't use an IRQ for net
<arokux>
oliv3r, dhcp worked from kernel for him
<oliv3r>
wens: IRQ 87 for A20
<jemk>
ssvb: no, haven't tried that yet, as i work around it by scaling to buffer at the moment
<oliv3r>
arokux: if it doesn't use the IRQ or something, yeah it can work; or it uses the wrong one and things get weird, but might still work :p
<jemk>
ssvb: so as far as i understand dri doesn't fit well with vdpau, as vdpau provides buffers and says "display that buffer" and dri is "i get a buffer i have to render to"
<arokux>
oliv3r, ok :)
<arokux>
oliv3r, what are you going to hack on next? maybe you could help me with usb host? ;)
<ssvb>
jemk: there are two things: one is the dri2 communication protocol, and another is the dri2 code in the ddx driver which currently manages the layers for mali
<ssvb>
jemk: the dri2 protocol itself is pretty limited, but it still can be used to notify the X server that you want to use some particular drawable for output, and notify the X server whenever you have the next frame ready
<ssvb>
jemk: and as I said, we can just hack in some extra communication channel for the additional details about buffers
<ssvb>
jemk: as for the code in the ddx, it already can track the windows stacking order and enable/disable layers when it is safe to do so
shineworld has quit [Quit: Leaving]
<ssvb>
jemk: so we can still use DRI2, but without letting it handle the buffers allocation :)
<jemk>
ssvb: ok, but two layers as discussed earlier, would that be possible with dri
<ssvb>
jemk: we add an ioctl for cedar, and the ddx driver can call this custom ioctl and get the information about the current video buffer placement in memory (and all the required layers)
<ssvb>
jemk: basically that would split the responsibilities in the following way: vdpau prepares the buffers in memory with the basic information about thre layers
<ssvb>
jemk: and xorg ddx driver takes care about their placement on screen by configuring disp layers, etc.
<jemk>
ssvb: ah, ok, i was to focused on how dri is used for 3d
atiti has quit [Ping timeout: 264 seconds]
<ssvb>
jemk: it is normally used for 3d, what I'm suggesting is a hack (very likely not approved by the xorg people) :)
<jemk>
ok ;)
BluesBoy has quit [Quit: HydraIRC -> http://www.hydrairc.com <- Nine out of ten l33t h4x0rz prefer it]
<wens>
oliv3r: setting the irq to 87 actually breaks it.
<wens>
oliv3r: same for the timers. can
<wens>
oliv3r: can't wrap my head around that one.
\\Mr_C\\ has quit []
<mripard>
oliv3r: actually, the compiler will do whatever it wants with "inline" functions, so it's not really a big deal
<mripard>
my point was more "use a function instead"
<mripard>
but you're right :)
<mripard>
and vinifr left
<mripard>
wens: two new branches appeared on my repo that should help you out a bit
<mripard>
but the first 32 interrupts in the GIC are per-processor-intrerutps, so those aren't counted in the bindings
leowt has quit [Quit: leowt]
<mripard>
so, the number to put in the devicetree is the number in the datasheet - 32
\\Mr_C\\ has joined #linux-sunxi
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
<wens>
mripard: could we document the interrupt offset somewhere?
<arokux>
naobsd, you brought this code to my attention, more wasn't needed
<arokux>
naobsd, I hope I'll add usb to mainline tonight!
<naobsd>
arokux: sounds very nice!
<arokux>
naobsd, ...as I hoped all previous nights :D
<oliv3r>
mripard: hmm, so the first 32 interrupts on the A20 aren't counted when mapping them? that sounds very confusing :p so the PPI and SGI ones i think
<naobsd>
:D
<oliv3r>
mripard: ok so # -32; the patch i did, should i add a collumn or something indicating IRQ?
<arokux>
naobsd, but there is awin_eth.c
<naobsd>
it's almost empty! just a skelton
<arokux>
naobsd, ah, ok
<naobsd>
register space is assigned, mii can be used
<naobsd>
that's all
<naobsd>
sleepy
<naobsd>
3AM now :(
<naobsd>
good night
arokux2 has joined #linux-sunxi
jemk has joined #linux-sunxi
sdfhrkr has joined #linux-sunxi
vrga has joined #linux-sunxi
<vrga>
'lo folks, just a quick question, when i want to toss tablet data on the mailing list, i should put it on the linux-sunxi one, right?
<atsampson>
vrga: yup, that's what the wiki suggests (and people do)
<vrga>
aight
<oliv3r>
arokux2: usbc0 is the OTG port, should work without it eventually ;)
<vrga>
should i attach script.bin or link it from my domain?
<arokux2>
oliv3r, not sure. ttyl
<vrga>
ergh. i'm not sure if my mail got through
<vrga>
ah, there we gi
<vrga>
*go
tinti has quit [Ping timeout: 245 seconds]
<jemk>
ssvb: i've met some problems with the two layer solution, maybe you have some ideas there too
<jemk>
ssvb: where do i get the video snippet for the overlay layer from? the scaler is already in use for video layer...
tinti has joined #linux-sunxi
<ssvb>
jemk: yes, that's an interesting problem
<ssvb>
jemk: but doesn't a10 have 2 scalers?
<jemk>
ssvb: a10 has, but a13 not
<ssvb>
a13 also does not have g2d
<jemk>
and im not very happy with using all resources for vdpau
sanka has joined #linux-sunxi
<jemk>
ah, realy? then there needs to be a software fallback either way
sanka has quit [Read error: Connection reset by peer]
<jemk>
second, if the video doesn't fill the whole output surface and something is displayed around it i think we need a third layer.
<jemk>
or either draw that with X or have to fall back to copy whole video
<ssvb>
depending on the progress made by libv, we might also use mali to do something
<ssvb>
what do you mean by saying video does not fill the whole output surface?
<ssvb>
ftp://download.nvidia.com/XFree86/vdpau/doxygen/html/group__api__winsys__x11.html - "VDPAU expects to own the entire drawable for the duration of time that the presentation queue target exists"
<jemk>
easy example: fullscreen with black borders. that would be easy if we don't exactly follow spec and allow them to be colorkey-color, but colorkey doesn't necessarily have to be black as player is free to chose it
<ssvb>
you mean the windows with the wrong aspect ratio? so that the black bars have to be added to fit the video correctly?
<jemk>
yes, or other players might even use the background_surface function of videomixer
<jemk>
vdpau doesn't ensure that video has to fill whole window, someone could get the idea to draw control elements with vdpau or something similar
notmart has quit [Quit: notmart terminated!]
<jemk>
or we simply say such cases would lead to slower fallback with copy, but at least black borders have to be fast
<ssvb>
hmm, but still the control elements are done entirely using vdpau api and bitmap surfaces?
<jemk>
i don't know if anyone does this, but it would be possible
<ssvb>
I mean, based on the spec it looks like X drawing is not supposed to be done with VDPAU drawable
<ssvb>
"Applications may also create child-windows of the presentation queue target, which will cover any presented video in the normal fashion. VDPAU implementations will not manipulate such child windows in any fashion"
sdfhrkr has quit [Remote host closed the connection]
<mturquette>
Turl: pong
<jemk>
the player shouldn't draw on the drawable but rather use bitmap surfaces, yes, but vdpau can do with drawable whatever it wants
<ssvb>
jemk: so to me it looks like vdpau provides some sort of a rectangle with its output, and this rectangle just fully covers the x11 window which vdpau owns
<jemk>
exactly
<jemk>
but not necessarily fully with video
<ssvb>
I don't see why vdpau would want to use x11 drawing api with its drawable
<ssvb>
other than ensuring the correct overlapping with the other windows
<ssvb>
via colorkey or other tricks
<jemk>
no, i don't *want* to use it, but maybe one needs to use it for the background
<jemk>
or another layer in disp, which would be the last of the 4 layers
<arokux2>
naobsd, still around? can you test if usb stick will work?
<naobsd>
arokux2: usb stick? root file system on usb storage?
<arokux2>
naobsd, so root on usb actually worked?
<arokux2>
rootfs*
<naobsd>
arokux: I can't try now
<arokux2>
naobsd, have you compiled all the new code already?
Soru has quit [Read error: No route to host]
<ssvb>
jemk: the ddx driver in xorg process has best control over the window, it knows when it gets moved, resized, gets overlapped by other windows, etc.
<ssvb>
jemk: so it can manage disp layers in a bit more reliable way than anything in the client process
<jemk>
ssvb: but can we use that already, or how much work is it to make it useable?
<ssvb>
jemk: it needs rather little amount of work
<jemk>
i don't have any knowledge about how *nix graphic systems work
<techn_>
oliv3r: who was going to implement mainline pwm driver?
<oliv3r>
techn_: i started it a whle ago; was trying to get sid merged so haven't looked at it for a bit; it was about 45% done
<oliv3r>
maybe 60%
<oliv3r>
needed 1 or 2 more functinos
<jemk>
ssvb: that would be good, but take your time, i won't have much time to work on this the next days
<techn_>
oliv3r: yeah. driver in stage/sunxi-3.4 seems to work
<techn_>
oliv3r: but it's not pretty :(
<oliv3r>
aye i saw
<oliv3r>
but for 3.4 its fine imo
<techn_>
sure
<naobsd>
arokux2: NetBSD kernel source? no, I just tried daily snapshot binary
<arokux2>
naobsd, ah, ok, so usb storage works?
<naobsd>
I can't try now
<naobsd>
I can't prepare file system on USB media for now
<arokux2>
naobsd, ok, thanks
<arokux2>
what is SDXC?
<hno>
high capacity SD cards > 2GB ( or >4GB)
<arokux2>
hno, thanks!
<oliv3r>
and SDHC is >32 GiB
<oliv3r>
SDXC was eXtended Capacity i belive
<hno>
rright. SDXC is > 32GB. SDHC is > 2GB.
<ojn>
mripard: did all the pieces land for a20 to be bootable on linux-next these days? i.e. pinctrl et al? It didn't come up on my cubieboard2 on a quick test but before I dig deeper I figured I'd check.
<popolon>
perhaps the USB OTG connector is not activated by some revamped linuw
<popolon>
linux
<popolon>
arokux, I try to fill USB ID database with usb id of cubieboards (or other allwinner powered devices
<arokux2>
popolon, ok
<deasy>
wait popolon
<popolon>
arokux2, which device have you ?
<deasy>
i boot on android
<arokux2>
popolon, Mele A1000
<deasy>
popolon, Bus 001 Device 003: ID 18d1:0003 Google Inc.
<popolon>
ok like me
<popolon>
arokux2, that use allwinner A10 isn't it ?
<arokux2>
popolon, yep
* atsampson
cheers as he finally gets a likely-looking A10 CyganogenMod image compiled... then boos as it fails the ro.product.device check when he tries to install it
<deasy>
see you tomorrow popolon :p
<popolon>
thanks deasy
<popolon>
no id durint the u-boot console too
<libv>
arokux2: posted.
<arokux2>
libv, thanks that you remember
<popolon>
Point of View Protab 2 XXL Tablet has also 18d1:0003 with android, the characteristics of the SoC looks like AllWinner A1x (1Ghz, 1Mali 400)
<popolon>
but don't find any precise information about this tablet SoC
<popolon>
arokux2, when you connect your melee to a PC, which usb id do you have for it ?