<willmore>
montjoie, once you have mastered masking the NMI, you have truely become the lockup master.
<fALSO>
lol
Da_Coynul has joined #linux-sunxi
<wens>
lol
<KotCzarny>
'truly'
Da_Coynul has quit [Client Quit]
gaston_ has joined #linux-sunxi
Da_Coynul has joined #linux-sunxi
<willmore>
KotCzarny, thanks. It's too early for me to English well.
<KotCzarny>
it's never too early for .. GRAMMAR.
<willmore>
That's spelling, not grammar. :)
<KotCzarny>
it's never too early for .. SPELLING.
<willmore>
And I disagree. It's way too early for humaning.
<KotCzarny>
humaning is completely different thing
<KotCzarny>
:)
<willmore>
:P
<KotCzarny>
it doesnt even have double letters
<swiftgeek>
willmore: still great `fortune` material
Da_Coynul has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
Da_Coynul has joined #linux-sunxi
chrisf_ has joined #linux-sunxi
tnovotny has joined #linux-sunxi
craigo has quit [Ping timeout: 245 seconds]
Da_Coynul has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
\\Mr_C\\ has joined #linux-sunxi
* wens
has an h3 driving a 4k display *facepalm*
<KotCzarny>
why a facepalm?
<libv>
is memory/bus bandwidth not able to keep up?
<wens>
software is too slow to redraw the screen. I see the cursor slowly drift as I move the mouse, at like 1/10 the speed
<wens>
might be because I'm using an overlay plane for it
<libv>
ah, software cursor
<KotCzarny>
:)
<libv>
are you, or are you not?
<wens>
libv: actually it's an overlay plane. but X11 cursor updates block everything else
<wens>
and it seems to update the cursor for every pixel of movement
<libv>
are you sure that you are not running into some block plane update thing?
<libv>
blocking even
<libv>
on the kms side
<libv>
why kms atomic is blockin at all is beyond me
<libv>
if they provided buffer flip events for planes, and atomic mode set events, it should be totally asynchronous
<wens>
libv: that's likely the problem.
<libv>
if i had been hired by intel in 2011, and ville (the guy who actually started atomic, but then was sidetracked) and i had been able to work on this full time, which would've been the first thing i would've pushed for, it would look pretty different
<wens>
I remember it was bad with full HD, but on 4k it's unusable
<fALSO>
damn u-boot is still borked
<fALSO>
i tried to tell them on #uboot
<fALSO>
but that seems to be a DEAD place
<libv>
wens: write up kms hwc, and just expose one less plane
<libv>
wens: make it a kconfig option
aballier has quit [Read error: Connection reset by peer]
<wens>
libv: you mean convert an overlay plane into hwc?
<libv>
yes, as a kconfig option
<libv>
either that, or you go fix kms
<libv>
h3 has multiple "layers" or overlays or planes (intel naming, at a time when intel had just dropped multiple overlays in their silicon) or whatever allwinner calls it
<libv>
and no actual hwc
<libv>
which makes sense for the android or tv usecase
<libv>
it's utter crap for the desktop usecase
<KotCzarny>
android also has a mouse pointer
<KotCzarny>
yet, it works ok
<libv>
KotCzarny: which is only used when you plug in a mouse
<libv>
how often does that happen, really?
<mru>
which nobody has ever done
<KotCzarny>
you can use mouse-mode with ir remote too
dddddd has joined #linux-sunxi
<libv>
i have
<KotCzarny>
or even keyboard
<libv>
anyway
<mru>
ok, I did once connect a mouse to an android tablet just to see if it worked
<libv>
add a kconfig option to sacrifice an overlay for a hwc
<KotCzarny>
i DO use wireless mouse+kb with my h3/droid
<libv>
see the desktop work smoothly
<KotCzarny>
it's a must without touch screen
<libv>
wens: incidentally, kms got cursor support for other than rgba 64x64 in like 2014 or 2015
<mru>
isn't android rather useless without touchscreen?
<libv>
gives you some idea of the quality of the work there.
<KotCzarny>
mru: works fine with wireless kb+mouse
<mru>
just like a regular desktop is useless with only a touchscreen
<KotCzarny>
or i might say, even better, because of hw kb
<mru>
when apps are made assuming one input mode, they tend to get awkward with any other
<KotCzarny>
tell that to folks porting games to/from consoles
<mru>
I'm sure they know already
<libv>
well, if kms had been done by actual display people, it would not be so entangled with 3d rendering infrastructure, and it would not have such obvious problems
<libv>
it took until the middle of this decade before they figured helper functions
<KotCzarny>
libv: that's what they got for dropping k.i.s.s. ?
<libv>
xfree86-4.0 is when they figured that out before
<libv>
the damage done by agressive and self-centered forks
<libv>
heh, 2000 is when that was released
<libv>
so the work on that, which was massive, started at least in 98 or before
<libv>
the first bigger driver for "kms" was a powerplay against radeonhd
<libv>
amd had hardhandedly told bridgman and his friends to stop competing with the real driver, especially since we were forced to use atombios as well (even tough the first new hw release was fully ported to the C code based driver with just a few lines)
<libv>
so this is how that was sidestepped, adhering to the commandment from above, and yet continuing the same game regardless
<libv>
between that, and how the kms header was created, and the randr1.2 halfarsedness it was based on, it is no miracle just how bad this all is
Da_Coynul has joined #linux-sunxi
Da_Coynul has quit [Ping timeout: 245 seconds]
aballier has joined #linux-sunxi
nexgen has quit [Ping timeout: 272 seconds]
<MoeIcenowy>
mru: at least android is partly useable with mouse
<MoeIcenowy>
but to be honest, when only a keyboard is available, android is really useless
<mru>
try doing a pinch gesture with a mouse
<wens>
use the mouse wheel lol
<mru>
and if that does something else?
<KotCzarny>
:)
<KotCzarny>
then someone is an idiot
<mru>
ever heard of scrolling?
<KotCzarny>
sure, drag the page and scroll
<KotCzarny>
it's the android's way
<mru>
then how do you select text?
<KotCzarny>
double click
<pmp-p>
last time i heard of it was sending up and down arrow keys :p
<KotCzarny>
then move those tiny selectors
<mru>
see, awkward
<KotCzarny>
sure, but doable
<mru>
I never said it was totally impossible
<mru>
does depend on the app though
<KotCzarny>
13:06 #linux-sunxi mru > isn't android rather useless without touchscreen?
<mru>
rather != utterly
rpirea has joined #linux-sunxi
<KotCzarny>
depends on region
<KotCzarny>
in british english it could mean just that
<KotCzarny>
;)
<mru>
depends on context too
<KotCzarny>
yup
kaspter has joined #linux-sunxi
<mru>
anyway, I connected a mouse to a tablet just now
<mru>
and the wheel scrolls the page in chrome
<mru>
dragging selects
<mru>
I can't find a way to zoom
<aalm>
ctrl+wheel?
<mru>
nope
<mru>
no zooming in maps either
<mru>
so pretty useless
<mru>
hmm, double-click zooms in a rather large amount
<KotCzarny>
i personally hate pinch-zoom, even on touchscreens
<mru>
can't seem to zoom out
<KotCzarny>
liked the buttons in ui
<KotCzarny>
but trend is to dumb down the interface
<aalm>
i don't like round things, that's where i've noticed things getting designed for touchscreens
<aalm>
we're loosing our rectangles:(
<libv>
aalm: just wait until apple designers go rectangular again
kaspter has quit [Ping timeout: 248 seconds]
rpirea has quit [Quit: rpirea]
rpirea has joined #linux-sunxi
salcedo has joined #linux-sunxi
<libv>
this whole sunxi_engine.h is trying to introduce layering where there should be none
<libv>
trying desperately to make up for artificial separation of modules
<libv>
and yet there's tons of holes poked into it, like including sun4i_backend.h in sun4i_crtc.c
salcedo has left #linux-sunxi ["WeeChat 2.5"]
<libv>
is the tcon or the hdmi block ever used without a debe attached? at no point do i see the dma bit from the diagram documented, and in our setup, the backend selects one or the other tcon block anyway...
lurchi_ is now known as lurchi__
nexgen has joined #linux-sunxi
kaspter has joined #linux-sunxi
merbanan has quit [Ping timeout: 272 seconds]
<cristian__c>
hi
<cristian__c>
I've fpund that micro-usb is not working on orange pi .ite and mainline kernel
<cristian__c>
it doesn't work at all, dmesg doesn't detect it and lsusb neither
<cristian__c>
I don't know why this happens
<karlp>
is it in device mode?
<cristian__c>
an user here told me this issue has been fixed in 5.1 or 5.2, but I've tried 5.2.5 and nothing hasnchanged
<karlp>
do you get anything in logs on the device in that case just from cable plug?
<karlp>
or ar eyou looking at the logs of where it's plugged into?
<cristian__c>
karlp: no, but I've tried it that m0de some months ago
<karlp>
how are you selecting the mode?
<mru>
first make sure the drivers are loaded
<cristian__c>
I've made that in April,May
<mru>
dmesg | grep musb
<cristian__c>
karlp: is host mode the default for that usb port. Isn't?
<cristian__c>
ok, I try
<karlp>
I don't know what it is, I was asking you :) but you might want to make sure.
<cristian__c>
I trymimmediately
<karlp>
(I'd expect a micro-B to be defaulting to device/otg, as that's what a B plug should be, not a host)
merbanan has joined #linux-sunxi
<cristian__c>
dmesg | grep musb returns nothing
<wens>
otg is not enabled for that board dts
<cristian__c>
I'm looking for the documebtation pafe
<cristian__c>
wens: but is it in host mode, then?
<cristian__c>
*page
<cristian__c>
wens: btw, g_serial is listed by lsmod
RichardG867_ has joined #linux-sunxi
RichardG867_ has quit [Changing host]
RichardG867_ has joined #linux-sunxi
RichardG867 has quit [Ping timeout: 250 seconds]
<cristian__c>
wens: do you talk about u-boot?
JohnDoe3 has joined #linux-sunxi
JohnDoe_71Rus has quit [Ping timeout: 246 seconds]
<martinayotte>
cristian__c: if you wish to get micro-usb as host, and you have this error in dmesg : "sun4i-usb-phy 1c19400.phy: Couldn't request ID GPIO"
<martinayotte>
The workround is to comment out "usb0_id_det-gpios" and force "dr_mode" being "host"
SopaXorzTaker has quit [Quit: Leaving]
<cristian__c>
martinayotte: I've looked for it in dmesg, but I've read nothing like that
<martinayotte>
cristian__c: which distro are you using ?
<cristian__c>
martinayotte armbian 5.91 buster, but I've also tried stretch some months ago
<wens>
cristian__c: the dts file in the kernel tree
<wens>
neither host controllers nor the otg controller are enabled
<cristian__c>
I look at linux kernel github mainline repository
<martinayotte>
... and it is OPiLite, right ? ... I've mine with "Linux orangepilite 5.2.0-sunxi #5.91 SMP" and with "dr_mode" = "host", I have it working ...
<cristian__c>
opilite, correct
<cristian__c>
ok, arch/arm/boot/dts
<cristian__c>
I've found that
<cristian__c>
martinayotte: is your sun8i-h3-orangepi-lite.dts different?
<martinayotte>
Armbian is using megous 5.2, but I'm searching, I think we have a patch on top of that ...
<cristian__c>
:O
<martinayotte>
Oh ! ... I've found it : it is a private patch sitting on my PC ... :-P
<fALSO>
found this, i dont remember my error, if its the same
<fALSO>
gonna check
<mru>
if it is, please reply to that message with what you found
<libv>
heh, stale .pyc?
<libv>
not cleaned out by mrproper?
<fALSO>
trying out building
Nakaori has quit [Ping timeout: 246 seconds]
<fALSO>
started using CCACHE
<fALSO>
its pretty cool
<libv>
yes, now it is happy
<mru>
also has a habit of breaking in difficult to debug ways
<libv>
git clean -dxf
<fALSO>
mru, LOL
<fALSO>
libv, that fixed the problem ?
<libv>
yes
<fALSO>
nice
<libv>
i was doing mrproper in between builds
<libv>
and that did not clean the pyc files
<fALSO>
i normally dont do it, my computer sucks
<fALSO>
and i want to re-use the compiled stuff
<libv>
so that needs to be addressed
<libv>
uboot was written by "embedded developers"
<libv>
they still have not made it into the 90s as they are still not using a device model everywhere
<fALSO>
heheh
<libv>
and can be built quickly
<libv>
mru: feel free to
<mru>
why must you be so condescending towards _everybody_?
<libv>
i was pretty happily using device model for coreboot when i wrote a display driver for that
<libv>
and was amazed that 5ys on, u-boot was all just globals
<libv>
and we're 5ys beyond that now
<fALSO>
well my error inst the same message of that guy
<fALSO>
binman: Unknown entry type 'blob' in node '/binman/blob'
<fALSO>
gonna try that git thingy
<mru>
when you need to fit as much functionality as possible into 28k of sram, a bit of elegance may need to be sacrificed
<libv>
fALSO: git clean -dxf and build from scratch
<mru>
if you're so damn good, why don't you write your own bootloader
<mru>
I'm sure it would replace u-boot in no time at all
<fALSO>
trying again
<libv>
as said, i have contributed to coreboot before
<libv>
and the first stage there used to run in cache
<fALSO>
good that i searched first, or i would make a fool of myself
<libv>
but's actually been a decade that i was there
<libv>
s/that/since/
<mru>
does coreboot run on anything but PCs?
<libv>
so i have no idea if or how they moved from there
<anarsoul>
yeah, it runs on chromebooks, even on ARM-based
<libv>
yes it does, but not sure how far armv7 went
<mru>
still very limited compared to what u-boot supports
<mru>
I actually agree that a lot of u-boot code is ugly as fuck
<libv>
or very broad considering what support they do bring up and provide to the booted OS
<mru>
much of u-boot developement is driven by actual product needs
<fALSO>
libv, thanks man, it worked!
<mru>
often very bizarre products
<libv>
it's the difference between a microcontroller developer writing up some small initialization code, and a linux guy cutting down a kernel to provide a full blown bios replacement
<libv>
hence "embedded developer"
<libv>
hence globals and whatnot
<fALSO>
hehe, i did some C code for STM32
<mru>
globals save a lot space
<fALSO>
the included libraries are somewhat.. WEIRD
<fALSO>
im also used to programming to computers, the "embebeded" people do things very differently
<fALSO>
hehe
<anarsoul>
libv: wanna show us an example and fit some DM-based drivers into 32kb SPL? :)
<libv>
anarsoul: let me dig out some cache sizes for via c7
<libv>
ah, 128kB, so that argument does not fly :)
<libv>
anarsoul: well, coreboot always did find good workarounds, and still used device model based drivers for anything but early init
<libv>
and 32kB sounds plenty to get a enough things working to move on
<libv>
having said that, i have not dealt with that part of the sunxi boot process
<anarsoul>
well
<libv>
all i did was write up a hdmi driver
<anarsoul>
I do some coreboot stuff for intel and amd platforms at work
<anarsoul>
and it's *way* easier on x86
<anarsoul>
you usually have 4-16mb of SPI flash that is mapped into memory space, so you don't need a driver to read rest of bootloader
<anarsoul>
oh, and you usually have plenty of L2-L3 that you can use as memory
<anarsoul>
coreboot folks never had to deal with limitations that u-boot deals with
<anarsoul>
also number of supported platforms is not comparable
<libv>
that does not mean that some basic structure is impossible
<anarsoul>
DM wasn't a thing yet when u-boot project was started
<libv>
it just never became a thing until very recently, due to the background of the original developers
<libv>
1999?
<libv>
same year as coreboot, then still linuxboot
<libv>
it's embedded/microcontroller developers versus linux developers, that's the fundamental difference
<libv>
and it shows, today still
<anarsoul>
linux still had *a lot* of platform specific stuff to poke different registers (gpio/pinmux/system configuration) back in 2009
<libv>
when i brought up the first native VGA driver for coreboot back in 2009, i was right at home. when i brought up the sunxi hdmi uboot driver, i was raising quite a lot of eyebrows
<libv>
back in 2014
<fALSO>
hehe
<libv>
again, back to the origin of this statement: embedded versus linux, it shows.
<fALSO>
systemd-uboot
<fALSO>
;-)
<libv>
i never said that u-boot does not have a place, i just said that there was some pretty arcane embedded thinking in there still
<libv>
i am happy though to have been proven wrong on not build testing such a major change
<libv>
and we here will not be the only ones falling into that one
kaspter has quit [Read error: Connection reset by peer]