<libv>
yay, Touchscreen page has some useful content!
FreezingCold has joined #linux-sunxi
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
kevin125 has joined #linux-sunxi
FDCX has quit [Ping timeout: 264 seconds]
Gerwin_J has quit [Quit: Gerwin_J]
tinti has quit [Quit: Leaving]
tomcheng86 has quit [Quit: leaving]
tomcheng76 has joined #linux-sunxi
lerc_ has quit [Ping timeout: 276 seconds]
petr has quit [Ping timeout: 268 seconds]
petr has joined #linux-sunxi
<wens>
mripard_: i did
naobsd has quit [Quit: Page closed]
<wens>
i don't know, maybe i'm missing something
Turl has quit [Remote host closed the connection]
FDCX has joined #linux-sunxi
Turl has joined #linux-sunxi
FreezingCold has quit [Ping timeout: 260 seconds]
lerc has joined #linux-sunxi
TheSeven has quit [Ping timeout: 272 seconds]
TheSeven has joined #linux-sunxi
pwhalen has quit [Ping timeout: 260 seconds]
pwhalen has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
akaizen_ has joined #linux-sunxi
akaizen has quit [Ping timeout: 272 seconds]
hipboi has quit [Ping timeout: 245 seconds]
amitk has joined #linux-sunxi
codekipper has joined #linux-sunxi
<codekipper>
libv: re:sunxi-boards/meminfo/....yep, that makes sense. I'll upload my devices when I get a chance.
hipboi has joined #linux-sunxi
<hramrach>
libv: I have looked at what people have for TS and it really looks like ts support is going to be a pita. The GSL1680 driver needs a firmware which is device specific. The driver in a23 sdk may be of some help but I am still not sure if it's easier to get this working or just replace the ouch layer in hardware :s
<mripard_>
wens: it would be great if you could test the MMC clock changes on the A23 too
<mripard_>
I could not test it in there, and I'd really like to get some more test coverage on that :)
avsm has joined #linux-sunxi
FR^2 has joined #linux-sunxi
kz1 has joined #linux-sunxi
<hramrach>
mripard_: what's with mmc on a23?
<wens>
hramrach: mmc clock updates
<hramrach>
on mainline?
<wens>
yes
<hramrach>
is it reasonably possible to boot mainline on a23 without uart?
<hramrach>
technically I could test mmc without using the mmc0 slot because I have a sdio wifi but it's probably not supported
<wens>
you have to have uart for the console, but you can skip the pinctrl part or something
<hramrach>
you can have console on the mmc pins
<wens>
anyway, since you only only boot from fel or fastboot atm, mmc is free :p
<hramrach>
I do not have those 2 testpoints next to the cpu
<hramrach>
yes, it's free but you cannot test mmc then
<wens>
hramrach: i'm using r_uart on my q8h, so my mmc is free
<hramrach>
what is r_uart?
Andy-D has joined #linux-sunxi
<wens>
it's the uart in the rtc block, shared by the main processor and the embedded processor
<hramrach>
but you still need pins for it
kz1 has quit [Quit: kz1]
<hramrach>
which are not connected to any known location on my board
<libv>
codekipper: thanks
<libv>
hramrach: yeah, but people need to be told how to get that firmware
popolon has joined #linux-sunxi
<libv>
hramrach: we should perhaps collect those firmwares in sunxi-boards/
<hramrach>
libv: it's not clear so far
<hramrach>
the module tends to include more than 1 firmware and the extract tools use some fuzzy logic to extract something
<hramrach>
so you end up with multiple files some of which look like actual ctp firmware and if you are lucky one of them works if you upload it to your gsl
<libv>
hramrach: there must be a way
<hramrach>
there is new tool in the works which will be hopefully more precise
<hramrach>
so it gets you fewer files which are very likely firmware and one of them will very likely work ten
<libv>
heh that n3rd_dude did not stick around
<hramrach>
+h
* libv
wonders if plaes got libvfever
<libv>
but nice, touchscreen seems to be getting some attention now
<libv>
thanks guys
<mripard_>
hramrach: it should be possible, but if it doesn't boot, you'll be in the dark
<mripard_>
so you have to be quite confident to do so :)
cubear has joined #linux-sunxi
<hramrach>
oh well. I will first try to boot the a10s olinuxino
<hramrach>
looks like the memory clock in the past year made it completely unbootable
<ssvb>
hramrach: I may be wrong here (it would be great if the hardware guys from olimex could correct me), but my understanding is that VDD is providing power to the DDR chip, it heeds to be 1.5V
<hramrach>
afaict from the schematics and datasheets it's so
<ssvb>
hramrach: then we have Vref voltage (which is VDD/2)
kz1 has joined #linux-sunxi
<hramrach>
but it may be set to 1.2V in most cases as a safe value that should work with both ddr3l and underclocked ddr3
<ssvb>
hramrach: and the DDR3 spec says that "DC input logic high" has the minimum value Vref + 0.100 and the maximum value VDD
<ssvb>
hramrach: basically, the signals on the data lines must be higher than Vref + 0.1 to be interpreted as logical 1
<hramrach>
that should not be a problem, should it?
<hramrach>
ddr3l is supposed to operate at 1.5v regardless, and 1.4V with some loss on the PCB would be about the 1.35V ddr3l nominal, either way
<hramrach>
But I guess I need to lover the speed to get this boot I guess
<ssvb>
hramrach: that's the ddr3 power voltage, and it is not related to dcdc3
jemk has joined #linux-sunxi
<hramrach>
so what does dcdc3 connect to?
<ssvb>
hramrach: as I understand it, the logical "1" signal on the ddr data lines is between 0.85V (VDD/2 + 0.1) and 1.5V (VDD)
<ssvb>
hramrach: the logical "0" is something below 0.75V (VDD/2)
<hramrach>
an if you lower vdd it's supposed to be lower ... if the chip is supposed to operate at that value
<hramrach>
in the olinuxino schematics all the vdd and vddq are connected to 1.5V rail which in other part of the schematics is connected to dcdc3
<ssvb>
hramrach: why would you lower vdd?
Black_Horseman has joined #linux-sunxi
<ssvb>
hramrach: hmm, is vdd really connected to dcdc3?
<hramrach>
because somebody set dcdc3 to 1.2V in fex
<hramrach>
it's what the schematic says
<ssvb>
hramrach: which one? and which part of it?
<hramrach>
Olinuxina A10S micro rev A - 512Mbytes DDR3 part and power part
stickyman has quit [Quit: Page closed]
<wens>
mripard_: mmc clk phase patches tested on sun8i, look good
<ssvb>
hramrach: that's the board you are experimenting with?
<hramrach>
yes, I wanted to connect it to a full HD screen
<hramrach>
meh
<ssvb>
hramrach: ouch, so dcdc3 is used to provide power for ddr3 chips on this board?
<hramrach>
seems so
<hramrach>
you have no other 1.5V source so I have no idea what you would power it with otherwise
MY123 has joined #linux-sunxi
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
<ssvb>
hramrach: now I wonder if dcdc3 voltage is also used for the DRAM controller part in the SoC on this particular board
<ssvb>
hramrach: or some other 1.2V source is just used instead
Seppoz has quit [Ping timeout: 250 seconds]
<hramrach>
it's connected to 1.5V in the schematics
<hramrach>
the VCC_DRAM pins on the SoC
<hramrach>
wow, cubietech finally made a usable case for CT
diego_r has quit [Ping timeout: 245 seconds]
philippe_fouquet has quit [Remote host closed the connection]
<ssvb>
hramrach: on A10 lime, dcdc3 seems to be connected to VDD_DLL and VDD_INT (and is labeled as 1.2V_INT)
<hramrach>
hmm
<hramrach>
I wonder which is more broken
<ssvb>
hramrach: on your A10S board, dcdc3 seems to be indeed labeled as 1.5V
<hramrach>
but then again you have only so many power rails on the AXP
<ssvb>
hramrach: and the SoC VDD_DLL/VDD_INT are labeled as 1.2V_INT and come from dcdc4 on A10s
<hramrach>
yes, and dcdc4 is set to 1.2V so that looks ok
<ssvb>
hramrach: somehow I don't believe that your ancient kernel was really setting 1.2V for dcdc3, maybe somebody just hacked the kernel code to suppress that :-)
<ssvb>
hramrach: and now you are trying to solve the puzzle
<hramrach>
it seems the same on CB. VDD and VDDQ on RAM Are from the same rail and that's also connected to the SoC VCC_DRAM
<hramrach>
ssvb: since dcdc3 defaults to 1.2 on other AXP I suspect you just need to underclock the ram more
amitk has quit [Quit: leaving]
amitk has joined #linux-sunxi
<hramrach>
hmm, on CB the schematic suggests that DRAM_VCC is suplied by separate regulator from DC-5V and has nothing to do with AXP at all
<ssvb>
hramrach: all board are providing 1.5V for DDR3 power regardless of their use of dcdc3
<ssvb>
hramrach: the A10s board from Olimex might be an oddball hardware
<ssvb>
hramrach: do we have schematics for any other A10s devices?
Andy-D has quit [Ping timeout: 240 seconds]
<hramrach>
I doubt. And using dcdc3 is just saving on regulators on the part of Olimex. Even Cubietech provides separat chips independent of AXP
<hramrach>
dcdc3 is used for DLLVDD on cb
<ssvb>
hramrach: in any case, the reliability of the DRAM controller in the SoC is dependent on VDD_DLL/VDD_INT voltage for A10/A20 hardware and we are configuring it with dcdc3
Seppoz has joined #linux-sunxi
<ssvb>
hramrach: the DDR3 power is always 1.5V
<Seppoz>
hi
<hramrach>
and DRAM_DLL does not connect to the chip in the cb schematic at all /o\
<hramrach>
maybe a schematic bug
<hramrach>
or I missed something
<ssvb>
hramrach: it looks like you just need to set 1.5V in fex for dcdc3 on this A10s board
<hramrach>
anyway, same AXP config for dcdc3 is used on the tablets - atarts on 1.5V as set by u-boot and then set to 1.2V
<hramrach>
but we have no idea what it's connected to there
<hramrach>
ok, so 1.5V it is
<hramrach>
incidentally, u-boot sets dcdc3 to 1.5V by default too
<hramrach>
on axp152 only
<ssvb>
still it does not make sense to set it to 1.5V in u-boot and then drop to 1.2V in the kernel, one of these settings must be wrong
<ssvb>
yes, for the Olimex A10s board both of these very likely need to be 1.5V according to the schematics
<ssvb>
but for A10s tablets 1.5V in u-boot might need a special investigation
<hramrach>
and a13
<hramrach>
because the chip is the same on these, right?
<ssvb>
can we trace the axp152 dcdc3=1.5V setup back to boot0 sources?
<hramrach>
it was in the initial AXP152 support commit and never changed
<hramrach>
other voltages were bumped
<hramrach>
b8823f80
cubear has quit [Quit: Leaving]
<ssvb>
hramrach: so Simon "theRat" must know something about it?
<hramrach>
or hans or henrik
<hramrach>
or they just patched it round and round until it booted ;-)
<ssvb>
rellla: yes, it is possible to rely on the kernel cmdline parameter for ve_size again
<ssvb>
hramrach: but it was rather difficult to reproduce
<hramrach>
100% here
<ssvb>
I guess, reverting to the vertex shader generated by the proprietary shader compiler is necessary
<ssvb>
lima_compiler is not good enough yet :(
<hramrach>
I cannot do commit revert
<ssvb>
yes, some other changes piled up
<ssvb>
just try to replace the "shader_v.h" file with the older version
<ssvb>
the shader source is not really used and kind of serves as a comment
<ssvb>
hramrach: if you can confirm that this fixes the problem, it would be a great help
<ssvb>
hramrach: I spent a lot of time trying to reproduce this bug and can't be even 100% sure that it was really this commit
<hramrach>
yes, reverting shader_v.h works
<hramrach>
I can see a cube
<ssvb>
hramrach: thanks for confirming!
<hramrach>
what issue would I see when I have memory bandwidth issue?
<hramrach>
and would it show with 400MHz ram clock?
<ssvb>
I guess, I will just move the current 'master' to the 'libre' branch and take the old vertex shader binary into use
<hramrach>
hmm, just rebooted
<libv>
heh, i think my semitime g2 might just work now
<hramrach>
432 even
FreezingCold has joined #linux-sunxi
<ssvb>
hramrach: as for the memory bandwidth, if you have 1920x1080-32@60Hz mode, then the whole screen is shaking up and down vertically if there are some issues with DEBE scanout
<hramrach>
I have that. The screen is 1920x1200 but it can apparently do 1080p as well
<hramrach>
when I have scaler disabled in fex debe is used, right?
<ssvb>
ok, maybe sun5i also has this problem fixed, just like sun7i
<ssvb>
yes, the disabled scaler is the most problematic setup
<ssvb>
hramrach: as for the reboot, it likely means that your dram settings are unreliable (testing the dram reliability is the primary purpose of the 'lima-memtester' program)
<hramrach>
the ancient rom probably has 384MHz and 300MHz mbus so much lower
<hramrach>
fb0_scaler_mode_enable = 0
<ssvb>
ok, thanks for running all these tests
<hramrach>
I also learned that A10 can actually scan out fullhd after all those problems
<hramrach>
thanks :)
nabblet has joined #linux-sunxi
<hramrach>
hmm, now it does not reboot
<hramrach>
maybe I touched the power cord or something the first time
<hramrach>
I have only mini USB for power and that's not exactly pinnacle of reliability
<ssvb>
then this is definitely not a power cord :)
<ssvb>
regarding dram reliability in general, increasing VDD_DLL/VDD_INT voltage up to something around 1.3V may help (you have it currently set to 1.25V from dcdc4, right?)
<ssvb>
or just reducing the dram clock speed until it can pass the test may be a reasonable action (and then reduce it by one more 24Hz step to have some extra safety headroom)
<hramrach>
this is for testing screen configuration not for top performance
<ssvb>
yeah, I understand
<hramrach>
incidentally the a10s seems much faster than the a13 tablets, though
<ssvb>
dram corruption is a rather serious issue by itself if you are going to use this board for anything practical
<ssvb>
that is unless you enjoy occasional oopses, mysterious crashes and deadlocks :)
<hramrach>
yes, that's why setting the clock lower is the first thing to try
F1skr has joined #linux-sunxi
<hramrach>
but the a10s support is seriously bitrotten. first the console thing that prevented libv from booting then the regulator thing that prevented me from booting, then the memory is clocked too high to run the board, and the board crashes in dualscreen configuration
<wens>
mripard_: i still have some patches for sun8i, mind if i just post them?
<libv>
hramrach: oh, dualscreen, yes, i get that too
<libv>
i have to set it to 0 each time
<libv>
i have no idea why it is set to 4
<libv>
anyway, i am unpacking my cubietruck now to go chase the libnand issue
pwhalen has joined #linux-sunxi
pwhalen has quit [Changing host]
pwhalen has joined #linux-sunxi
xavia has joined #linux-sunxi
zeRez has joined #linux-sunxi
Nyuutwo has quit [Ping timeout: 246 seconds]
avsm has joined #linux-sunxi
<hramrach>
ssvb: with 384MHz I get the jumping
<hramrach>
only the cube jumps and not the background but it's quite obvious
forcev has quit [Ping timeout: 246 seconds]
FunkyPenguin has joined #linux-sunxi
zeRez has quit []
<hramrach>
enabling scaler seems to fix the issue but *decreases* bandwidth reported by lima-memspeed fb_scanout gpu_write from 958 to 912
FR^2 has quit [Quit: Connection reset by peer]
zeRez has joined #linux-sunxi
<ssvb>
hramrach: :)
philippe_fouquet has quit [Remote host closed the connection]
<libv>
heffer: your SDK-758 is just 2 patches away from being complete
<ssvb>
hramrach: this only eliminates the shaking issue for the scaler mode alone (which seems to be already fine for you), but may still increase the performance
akaizen_ has quit [Remote host closed the connection]
akaizen has joined #linux-sunxi
<hramrach>
crash..
akaizen has quit [Ping timeout: 272 seconds]
<ssvb>
hramrach: just at 384mhz? or after tweaking the DEFE host port priority?
<hramrach>
just 384MHz
<ssvb>
hramrach: this sucks
<hramrach>
I try bump dcdc4 some more
konradoo77 has joined #linux-sunxi
<hramrach>
hmm, I actually should do that in fex rather than u-boot
zeRez has quit []
<hramrach>
it's not in fex?
<ssvb>
hramrach: it was in the kernel log though?
<hramrach>
[ 1.916070] axp152_dcdc4: 1250 mV
<ssvb>
hramrach: also you can check the 'emr1' parameter in 'dram_para' in u-boot, it is typically set to 0x0 or 0x4 (and you can try a different value)
<hramrach>
dram_emr1 = 0x4
<ssvb>
hramrach: you can change it to 0 and check if this improves reliability in lima-memtester
<netlynx>
hi
<hramrach>
hmm, setting the port priority gives 1024.9 MB/s
<hramrach>
that's more than with 432MHz initially
zeRez has joined #linux-sunxi
<hramrach>
but cube jumping is back
<hramrach>
so I guess the number does something different on sun5i
<ssvb>
hramrach: yeah, that's weird
<hramrach>
it's actually worst I have seen
<hramrach>
changing fex changes the voltage in dmesg so that part works
<ssvb>
hramrach: for the host port, you can try to change 0x5031 -> 0x6031 (basically, increase the value in the high byte until the jumping disappears)
<ssvb>
hramrach: I only tested it on lime with the dram clocked down to 408MHz, but your clock speed is even lower
<ssvb>
hramrach: and are you still using 1920x1200 screen resolution? it is tougher than 1920x1080
<hramrach>
but I got from no jumping to very bad jumping by this: http://sprunge.us/fKLd
<hramrach>
so either it's the wrong value or it works differently on this hw
konradoo77 has quit [Ping timeout: 255 seconds]
<hramrach>
and no, I ma not using 1920x1200 because the kernel just ignores the EDID it reads and decodes
<ssvb>
hramrach: this change reduces priority for DEFE to make it equal with the CPU/GPU, but increases the allowed bandwidth use percentage
<hramrach>
what is that 0x0735 part?
<ssvb>
hramrach: if DEFE priority is higher than the priority of CPU/GPU, then the dram controller can't reorder requests from DEFE and CPU/GPU relative to each other, and may result in a pathologically bad performance
<hramrach>
do we have something similar for sun5i?
<ssvb>
we believe that the host ports assignment is exactly the same
<ssvb>
and the changes you make are clearly taking effect (you can see some difference), so you are changing the settings for the right port :)
<hramrach>
indeed, it did not shake with the original value
<hramrach>
actually, it did slightly shake
<hramrach>
so increasing priority of the wrong port would have this effect too
MY123 has joined #linux-sunxi
<hramrach>
which looks like what is happening here
<hramrach>
can you program this at runtime?
<ssvb>
hramrach: yes, I believe so
F1skr has quit [Quit: WeeChat 1.0]
<ssvb>
hramrach: but ultimately, your current dram clock speed may be a bit low for FullHD, considering that A10s has 16-bit bus width
<ssvb>
hramrach: FullHD needs at least 500MB/s of the memory bandwidth for screen refresh
lkcl has quit [Ping timeout: 276 seconds]
<ssvb>
hramrach: but because of inefficiencies here and there, the bandwidth is not 100% perfectly utilized, so the screen refresh in practice costs more
<hramrach>
I set the 4th value to 1031 and the shaking .. makes slightly different cube patterns than f031 so does not appear as wobbly but that's it
zeRez has joined #linux-sunxi
<hramrach>
well, the reported total bandwidth is 1023.5 MB/s with this value as is with and xx31 value
lkcl has joined #linux-sunxi
<hramrach>
so that port is used in the test at least
Nyuutwo has joined #linux-sunxi
<ssvb>
hramrach: when you have half of your memory bandwidth wasted on screen refresh, it is not very healthy in general
<ssvb>
hramrach: if we find a way to configure this device for faster dram clock speeds, then it may improve the situation
<hramrach>
without doing screen refreshes the board is useless so even if 75% of bandwidth was used that's fine
<MY123>
hramrach: Lower res?
<ssvb>
hramrach: you always have an option to use lower screen resolution, lower color depth or lower refresh rate :)
<hramrach>
so the thing is that you cannot actually do fullhd with stable memory timings
<ssvb>
hramrach: if your current dram settings have .cas=9, then the timings are way too wasteful for such low clock speed
<hramrach>
hmm, probably
<ssvb>
the cas=9 timings are supposedly for 667MHz (!) and you are clocking the memory at only 384MHz
<hramrach>
they are probably wasteful for 432MHz too
<ssvb>
sure
<hramrach>
I use whatever was for olinuxino in u-boot
<ssvb>
you can run "./a10-dram-timings-calculator 384" and use this as a template for the u-boot dram_para struct
<ssvb>
actually you can use it as-is and only add your own 'emr1', 'zq', 'odt_en' and 'trp3' parameters (if you want to do additional tuning)
<hramrach>
so
<hramrach>
I set the port to f037 and my cube is crisp and clear
<plaes>
libv: you're welcome ;)
<hramrach>
and bandwidth reported dropped to 913
<hramrach>
so the memory bandwidth provide by the board suffices, more or less
<hramrach>
but why do you have to raise DEFE above DEBE when DEBE is supposedly not used?
<ssvb>
not above DEBE, but above CPU and GPU
<ssvb>
because CPU and GPU are competing for the memory bandwidth
<plaes>
libv: does this ({{Remove:TODO:}} [[Touchscreen#Device|Manufacturer Device]]) look ok?
<hramrach>
the third is GPU?
<ssvb>
the first and second are the CPU and GPU
<hramrach>
I tried 2033 and it did not work. not sure if I tried f033 anymore
<MY123>
plaes: I seen you have done an edit to the page.
<MY123>
(does FocalTech produce the full touchscreen or controllers?)
<ssvb>
hramrach: you also have the a10-lime, right?
<hramrach>
yes, it was here somewhere
<ssvb>
hramrach: having both a10-lime and a10s, you can collect much more experimental data about the best host ports configuration for FullHD resolution than I can
<hramrach>
ssvb: there is some threshold there. setting the value to 6033 does not have visible result but 6037 does although technically either is above anything else with DEBE set to 0301
<hramrach>
ssvb: you can run the lime on 384MHz or did you have to tune it to run at higher clock to be able to scan out fullhd?
<hramrach>
even 1037 does it
<ssvb>
hramrach: lime runs dram at 480mhz by default, that's why I artificially reduced it to 408mhz in order to have some headroom for the screen shaking effect elimination
konradoo77 has quit [Ping timeout: 276 seconds]
<hramrach>
when I raise the priority of DEBE to some high value like 1037 I get a bit less bandwidth total in lima-memspeed but working scanout
<hramrach>
interestingly, 1033 or 1031 gives similar result.
<hramrach>
that is when it fails to scan out I get about 1025MB/s and when it works about 912MB/s
<hramrach>
with 384MHz
konradoo77 has joined #linux-sunxi
<hramrach>
at 432 there was no issue at all with the default setting
<ssvb>
the bit number 1 is reserved according to the information that we have, that's why 1033 and 1031 are supposed to be identical
bonbons has joined #linux-sunxi
<hramrach>
but the original value of 1035 did nit work either
<hramrach>
is that supposed to be identical to 1033?
<ssvb>
no, 0x5 = 0101 in binary format, and 0x3 is 0011 in binary format
<hramrach>
well, there is some unknown here
<ssvb>
the lowest bit 0 is "port enable", it needs to be set to 1
<ssvb>
the next bit 1 is reserved
<ssvb>
the bits 3:2 are setting the port priority
<ssvb>
so 0x5 means "port is enabled with priority 1", and 0x3 means "port is enabled with priority 0, and the unused reserved bit is set to 1"
<hramrach>
and 1037 and 1035 should be identical except for the reserved bit
<hramrach>
but behave differently so it looks like it is not reserved on sun5i but actually does something
<ssvb>
maybe
quitte has joined #linux-sunxi
<hramrach>
anyway, value 1037 works for me even with very low clock
quitte_ has quit [Write error: Broken pipe]
<ssvb>
so flipping the supposedly reserved bit does all the magic? sounds great
<hramrach>
seems so
<ssvb>
we may want to check if this helps for the a10 too
<hramrach>
but you need to have high priority port for it to work. does not work with 1033
<hramrach>
but you have it in the current config anyway
<hramrach>
not using high priority gives you more overall bandwidth but does not suffice on 384MHz
<hramrach>
hmm, ok
<hramrach>
I guess it's time to look into setting the value at runtime
<lauri>
Hi guys
<hramrach>
there are too many to reboot every time
<hramrach>
hello
<lauri>
I am having VDPAU artifacts with dan-3.4.103 and libvdpau-sunxi 0.2
<lauri>
It appears that with fast moving scenes it's flipping between prev/next frame
<lauri>
hard to explain
<hramrach>
I think jemk did something with cedar?
<hramrach>
heh, can't test this at home because I have no fhd screen
bengal has quit [Ping timeout: 268 seconds]
y0g1 has joined #linux-sunxi
<lauri>
I am not sure but it might affect only certain h264 profiles?
netlynx has quit [Quit: Leaving]
y0g1 has quit [Read error: Connection reset by peer]
y0g1 has joined #linux-sunxi
<lauri>
yep, it seems 1080p high bitrate files are okay
<lauri>
lower resolution h264 files are jerky
<jemk>
lauri: what player? mpv?
y0g11 has joined #linux-sunxi
<lauri>
yep mpv
y0g1 has quit [Read error: Connection reset by peer]
<lauri>
I am not sure but it also seemed for 1080p playback vsync was broken?
<libv>
oh, that was only 9 months ago when i created that page
<lauri>
dude you're talking so figuratively I have no clue what you're talking about :D
<libv>
my bad.
eagles0513875 has joined #linux-sunxi
MY123 has quit [Quit: Connection closed for inactivity]
<libv>
heh, even a80 sdk still uses livesuit306
Black_Horseman has joined #linux-sunxi
arend has quit [Remote host closed the connection]
Renard- has joined #linux-sunxi
<Herm>
hi! who is responsible for the wiki? I would like to contribute some content regarding the LVDS interface but it says "Your username or IP address has been blocked. The block was made by DNSBL. The reason given is Your IP address is listed as an open proxy in the DNSBL used by linux-sunxi.org.."
<Herm>
my IP is not actually an open proxy, but the AFTR (ipv6 to ipv4 translation) from my cable company. They don't provide native ipv4 access anymore
mmarker has quit [Read error: Connection reset by peer]
<libv>
when does it say that?
<libv>
when you try to register?
mmarker has joined #linux-sunxi
<Herm>
when trying to edit any page
xavia has quit [Remote host closed the connection]
<libv>
so you already have a valid account?
<Herm>
no
<Herm>
but trying to register gets the same error message
<Herm>
Login error
<Herm>
Your IP address is listed as an open proxy in the DNSBL used by linux-sunxi.org. You cannot create an account (95.90.194.101)
<libv>
...
<libv>
so how does it then _NOT_ say that when you try to register?
<Herm>
it says I can't create an account
<libv>
and why are we not ipv6 reachable?
<Herm>
linux-sunxi.org doesn't have an ipv6 address
<libv>
apparently
<libv>
Herm: you must be getting blacklisted like this all the time
<Herm>
actually this is the first site I expecienced this problem
<Herm>
experienced
<libv>
hrm, you seem to be in germany, right?
<libv>
if so, which isp is this?
<Herm>
kabel deutschland
<libv>
heh, the previous tennant here had that installed. i am glad i chose a more normal provider
<libv>
is your scribus email address still valid?
<libv>
if not, /msg me a valid one
physis has joined #linux-sunxi
jemk has quit [Quit: leaving]
konradoo77 has quit [Ping timeout: 276 seconds]
<libv>
ok, so apparently, in this case, creating an account for someone else gets that someone past this barrier
physis has quit []
paulk-collins has quit [Quit: Ex-Chat]
lerc has joined #linux-sunxi
arete74 has joined #linux-sunxi
arete74_ has quit [Ping timeout: 268 seconds]
MackBoy_ has joined #linux-sunxi
Herm has quit [Ping timeout: 268 seconds]
Herm has joined #linux-sunxi
BluesBoy has quit [Ping timeout: 268 seconds]
VargaD has quit [Ping timeout: 276 seconds]
codyps has quit [Ping timeout: 276 seconds]
eagles0513875 has quit [Ping timeout: 276 seconds]
MSameer has quit [Ping timeout: 276 seconds]
MackBoy has quit [Ping timeout: 268 seconds]
MSameer has joined #linux-sunxi
codyps has joined #linux-sunxi
Turl has quit [Ping timeout: 268 seconds]
petr has quit [Ping timeout: 276 seconds]
Guest49263 has quit [Ping timeout: 276 seconds]
BluesBoy- has joined #linux-sunxi
petr has joined #linux-sunxi
wens_ has joined #linux-sunxi
wens has quit [Write error: Broken pipe]
BluesBoy- is now known as BluesBoy
moofree has quit [Ping timeout: 276 seconds]
Turl has joined #linux-sunxi
moofree has joined #linux-sunxi
VargaD has joined #linux-sunxi
fredy has joined #linux-sunxi
deasy has quit [Quit: Nom d'un quark, c'est Edmonton !]
ricardocrudo has quit [Ping timeout: 272 seconds]
eagles0513875 has joined #linux-sunxi
deasy has joined #linux-sunxi
phh_ has joined #linux-sunxi
lkcl_ has joined #linux-sunxi
captaini- has joined #linux-sunxi
arokux1 has joined #linux-sunxi
ijc has quit [Ping timeout: 240 seconds]
wigyori_ has joined #linux-sunxi
apo__ has joined #linux-sunxi
ijc has joined #linux-sunxi
rah_ has joined #linux-sunxi
eagles0513875 has quit [*.net *.split]
Herm has quit [*.net *.split]
MackBoy_ has quit [*.net *.split]
bertrik has quit [*.net *.split]
tomcheng76 has quit [*.net *.split]
FDCX has quit [*.net *.split]
montjoie[home] has quit [*.net *.split]
captainigloo has quit [*.net *.split]
rah has quit [*.net *.split]
jelly-home has quit [*.net *.split]
huehner has quit [*.net *.split]
ojn has quit [*.net *.split]
Wizzup has quit [*.net *.split]
captaini- is now known as captainigloo
andoma_ has joined #linux-sunxi
jelly-ho- has joined #linux-sunxi
Seppoz has quit [Remote host closed the connection]
ojn has joined #linux-sunxi
Wizzup has joined #linux-sunxi
tomcheng76 has joined #linux-sunxi
huehner has joined #linux-sunxi
montjoie[home] has joined #linux-sunxi
lynxis has quit [*.net *.split]
kelvan has quit [*.net *.split]
discopig has quit [*.net *.split]
joga has quit [*.net *.split]
petr_ has joined #linux-sunxi
bertrik has joined #linux-sunxi
speakman_ has joined #linux-sunxi
speakman has quit [Ping timeout: 260 seconds]
ganbold__ has joined #linux-sunxi
Wes- has quit [Ping timeout: 255 seconds]
tomcheng76 has quit [Ping timeout: 255 seconds]
Renard- has quit [Ping timeout: 255 seconds]
ganbold_ has quit [Ping timeout: 255 seconds]
phh_ has quit [Ping timeout: 255 seconds]
lerc has quit [Ping timeout: 255 seconds]
hipboi has quit [Ping timeout: 255 seconds]
phh__ has joined #linux-sunxi
rafaelMOD has quit [*.net *.split]
joga_ has joined #linux-sunxi
VargaD has quit [Ping timeout: 260 seconds]
petr has quit [*.net *.split]
lkcl has quit [*.net *.split]
pwhalen has quit [*.net *.split]
apo_ has quit [*.net *.split]
andoma has quit [*.net *.split]
arokux has quit [*.net *.split]
wigyori has quit [*.net *.split]
Montjoie has quit [*.net *.split]
phh has quit [*.net *.split]
hramrach has quit [*.net *.split]
tomboy64 has quit [*.net *.split]
oliv3r_ has joined #linux-sunxi
egbert has quit [Disconnected by services]
arete74_ has joined #linux-sunxi
egbert has joined #linux-sunxi
npcomp_ has joined #linux-sunxi
Celia has joined #linux-sunxi
tomcheng76 has joined #linux-sunxi
VargaD has joined #linux-sunxi
specing_ has joined #linux-sunxi
MSameer_ has joined #linux-sunxi
rah_ has quit [*.net *.split]
MSameer has quit [*.net *.split]
arete74 has quit [*.net *.split]
bonbons has quit [*.net *.split]
TheSeven has quit [*.net *.split]
link0 has quit [*.net *.split]
oliv3r has quit [*.net *.split]
skaag has quit [*.net *.split]
Akagi201 has quit [*.net *.split]
npcomp has quit [*.net *.split]
FergusL has quit [*.net *.split]
specing has quit [*.net *.split]
diego71 has quit [*.net *.split]
MSameer_ is now known as MSameer
specing_ is now known as specing
TheSeven has joined #linux-sunxi
lerc_ has joined #linux-sunxi
Renard- has joined #linux-sunxi
lauri__ has joined #linux-sunxi
bsdfox has quit [Ping timeout: 246 seconds]
lauri has quit [Ping timeout: 246 seconds]
indy has quit [Ping timeout: 246 seconds]
Nyuutwo has quit [Ping timeout: 246 seconds]
joga_ has quit [Ping timeout: 246 seconds]
bertrik has quit [Ping timeout: 246 seconds]
Montjoie has joined #linux-sunxi
Akagi201 has joined #linux-sunxi
wigyori_ has quit [Ping timeout: 246 seconds]
deasy has quit [Ping timeout: 246 seconds]
diego71 has joined #linux-sunxi
mturquette has quit [Ping timeout: 246 seconds]
hipboi has joined #linux-sunxi
bertrik has joined #linux-sunxi
Wes- has joined #linux-sunxi
Nyuutwo has joined #linux-sunxi
__builtin_yuno has quit [Ping timeout: 246 seconds]
skaag has joined #linux-sunxi
BluesBoy has quit [Ping timeout: 276 seconds]
egbert has quit [Ping timeout: 276 seconds]
petr_ has quit [Ping timeout: 276 seconds]
petr has joined #linux-sunxi
petr has quit [Changing host]
petr has joined #linux-sunxi
petr has quit [*.net *.split]
indy_ has joined #linux-sunxi
petr has joined #linux-sunxi
egbert has joined #linux-sunxi
petr is now known as Guest71019
mturquette has joined #linux-sunxi
mturquette has quit [Changing host]
mturquette has joined #linux-sunxi
joga has joined #linux-sunxi
kelvan has joined #linux-sunxi
joga has quit [Ping timeout: 260 seconds]
77CAAFYI1 has joined #linux-sunxi
rah has joined #linux-sunxi
Renard- has quit [Ping timeout: 252 seconds]
tomcheng76 has quit [Ping timeout: 252 seconds]
speakman_ has quit [Ping timeout: 252 seconds]
MSameer has quit [Ping timeout: 252 seconds]
tomcheng76 has joined #linux-sunxi
kelvan has quit [Read error: Connection reset by peer]
Akagi201 has quit [Ping timeout: 252 seconds]
MackBoy has joined #linux-sunxi
arokux1 has quit [Ping timeout: 252 seconds]
kelvan has joined #linux-sunxi
Akagi201 has joined #linux-sunxi
kelvan has quit [Excess Flood]
diego71 has quit [Ping timeout: 252 seconds]
diego71 has joined #linux-sunxi
__builtin_yuno has joined #linux-sunxi
__builtin_yuno has joined #linux-sunxi
lkcl_ has quit [Ping timeout: 252 seconds]
lkcl_ has joined #linux-sunxi
yann_s has quit [Ping timeout: 260 seconds]
yann_s|AFK has joined #linux-sunxi
yann_s|AFK is now known as yann_s
__builti1_yuno has joined #linux-sunxi
pwhalen_ has joined #linux-sunxi
kelvan has joined #linux-sunxi
kelvan_ has joined #linux-sunxi
kelvan has quit [Ping timeout: 260 seconds]
MSameer has joined #linux-sunxi
speakman has joined #linux-sunxi
arokux1 has joined #linux-sunxi
link0 has joined #linux-sunxi
__builtin_yuno has quit [Ping timeout: 268 seconds]
speakman has quit [Changing host]
speakman has joined #linux-sunxi
kelvan_ has quit [Remote host closed the connection]