<Wizzup>
uvos: I think probably 5.14 needs the leste-config for pine64, but 5.10 still uses the old one
Pali has quit [Ping timeout: 256 seconds]
xmn has quit [Quit: ZZZzzz…]
joerg has quit [Ping timeout: 240 seconds]
joerg has joined #maemo-leste
<sicelo>
sxmo definitely uses 3d, although they're now in the process of completely switching to wayland
<sicelo>
iirc they currently use x and wayland in parallel (sxmo, swmo)
zhxt has joined #maemo-leste
<tmlind>
Wizzup: sounds like fremantel bandgap is only periodically enabled, looks like oma34xx is missing the thermal shutdown features
<tmlind>
Pali: so is your bme taking care of charger thermal shutdown?
<freemangordon>
IIRC, on fremantle nokia kernel bandgap was not enabled/used at all
<freemangordon>
in kernel-power we enabled it, but I am not sure we used it at all
<freemangordon>
battery thermistor is used for temperature measurement, if I am not mistaken
<freemangordon>
'battery' means it is close to battery, not built-in to
<freemangordon>
joerg: do you remember how it all was? ^^^
<tmlind>
freemangordon: i'm mostly worried about what shuts down the system if battery overheats during charging, i guess there's no hardware based thermal shutdown on bq27200?
<tmlind>
hmm maybe the charger needs to be kicked periodically to keep charging enabled?
<tmlind>
heading out here, on a spotty connection on my d4
<freemangordon>
userspace shuts it down
<freemangordon>
there is a dsme plugin which reads temperature from bme (iirc), lemme check
<freemangordon>
tmlind: so, dsme plugin reads MADC temperature sensor values and reports temperature to dsme, which takes overheat shutdown decision. OMAP sensor seems to be explicitly disabled
<freemangordon>
pali: please confirm ^^^
<freemangordon>
hmm, I shal pull that to leste, at least for n900
<freemangordon>
though I guess it makes sense for all devices
Wikiwide_ has joined #maemo-leste
<Wizzup>
freemangordon: point is that atm bandgap is unstable
<Wizzup>
having it loaded with cpu_thermal causes oopses
<freemangordon>
Wizzup: yes, I know, but that seems to be a kernel driver issue
uvos has joined #maemo-leste
<freemangordon>
nokia disabled it because the reading is useless
<freemangordon>
AFAIK
<freemangordon>
not to say I still hold on to "on mobile it is userspace that shall take shutdown decisions"
<Wizzup>
I suppose from kernel perspective there might not be mobile userspace
<uvos>
i think reling on userspace of thermal shutdown is bad design
<uvos>
*for
<freemangordon>
sure, but userspace should at least have a knob to tell kernel "don;t kare about thermal shutdown stuff"
<freemangordon>
*care
<freemangordon>
uvos: not really, kernel doesn;t have all the information
<freemangordon>
BTW, the same goes for low battery
<freemangordon>
kernel has no idea of "emergency call"
<uvos>
you can maybe have it turn it off in parts yeah
<uvos>
but the kernel must support it
<uvos>
userspace is not allways runing
<freemangordon>
sure
<uvos>
or reactive
<freemangordon>
no doub;t about that
<freemangordon>
I am saying that userspace should be able to take over that
<Wizzup>
sicelo: well the question was do they use glamor
<freemangordon>
Wizzup: sorry for not helping you with xorg, I change that today :)
<Wizzup>
freemangordon: no worries, I built it already
<freemangordon>
I had 2 almost sleepest nights having to take care of some production issues in one of the systems we support
<Wizzup>
it doesn't change that much for pinephone unfortunately though it seems
<Wizzup>
yikes
<Wizzup>
java? :p
<freemangordon>
no
<freemangordon>
TAL :p
<uvos>
someone mentioned that accel dosent work on pp on dri2
<freemangordon>
ever heard about?
<uvos>
so glamor is the only choice
Pali has joined #maemo-leste
<uvos>
if thats true
<freemangordon>
Wizzup: it was not related to log4shell
<freemangordon>
it was a planned migration which almost turned out to be a disaster because the SW provider left a bug in one of the file conversion routines
<Wizzup>
freemangordon: yikes
<freemangordon>
yeah :)
<Wizzup>
uvos: what accel would that be?
<freemangordon>
dri3
<freemangordon>
I guess
<Wizzup>
uvos: also it's surprisingly smooth in portrait, but not in landscape
<uvos>
any kind of 3d
<Wizzup>
but there are real weird bugs, like just having conversations open causes it to glitch on the edges near the screen
<uvos>
(ie client or x's own rendering)
<Wizzup>
it keeps wiggling around
<freemangordon>
Wizzup: because it is rotated in SW
<Wizzup>
like some animation that never stops
<uvos>
its rotated in gl
<uvos>
not sw
<freemangordon>
not really
<uvos>
yes really
<freemangordon>
how do you know?
<uvos>
it uses the glamor pixmap rotating function
<uvos>
for the framebuffer
<freemangordon>
it doesn;t makes sense to me then
<uvos>
i traced this some time ago
<Wizzup>
you have a pp? I forgot
<uvos>
no
<uvos>
i traced how glamor rotates
<freemangordon>
PP has powerful GPU, it should not make it stutter on GL rotation
<Wizzup>
well in landscape it is so slow I thought it was llvmpipe
<uvos>
on desktop
<freemangordon>
uvos: it is not glamor, but modesetting
<uvos>
yes/no
<uvos>
or really no
<freemangordon>
Wizzup: maybe try to disable shadow framebuffer
<Wizzup>
ok
<freemangordon>
and see if it gets better
<Wizzup>
freemangordon: this 1 bit font problem you found btw
<Wizzup>
does that cause fonts to get rendered poorly?
<uvos>
so theres a file part of the randr extenstion that sets the transformation matrix property on the pixmap of the root window
<freemangordon>
Wizzup: will provide pacthes later on
<Wizzup>
ok
<uvos>
the other window's pixmaps are subwindows of the root window ofc
<uvos>
so they all get it
<uvos>
this makes glamor apply all the matrixies in the normal pximap rendering pipleine
<uvos>
causeing everything to be rotated
<uvos>
this dosent touch the ddx at all
<freemangordon>
ok, but that doesn;t explain the slowness
<uvos>
it stays at native oritation
<uvos>
sure i have no idea why its so slow on pp
<freemangordon>
GL doesn;t really care if it is rotated on 0 or 270 degrees
<freemangordon>
so it must be modesetting doing SW pixmap copy to the shadow FB
<freemangordon>
the same I was seeing on d4/n900
<uvos>
thats not true tho
<uvos>
iirc glamor uses a diferent path for pixmaps that dont have a transformation matrix set and ones that do iirc
<freemangordon>
uvos: wait, you were saying it is kernel that shall rotate, no you say glamor
<freemangordon>
*now
<uvos>
?
<uvos>
no xorg has internal transformation matrixes
<uvos>
not the planes
<freemangordon>
I remember we were discussing that modesetting shall set atomic property for the kernel to roatate
<freemangordon>
ah, ok
<uvos>
this is something else
<uvos>
these are used by glamor to rotated windows
<freemangordon>
but who takes the decision what to use?
<uvos>
(even indipendant of full screen rotation)
<uvos>
randr
<freemangordon>
then maybe we have a bug in randr
<uvos>
or really not
<uvos>
it just sets the matrix
<freemangordon>
because I can confirm on d4 rotation was done in SW
<uvos>
in non accelerated x the matrix just dose nothing
<uvos>
and modesetting rotates in ddx
<uvos>
so the framebuffer is really roated
<freemangordon>
for modesetting/glamor
<uvos>
the decision is implicit
<uvos>
the matrixies are allways there
<uvos>
but only glamor uses it
<uvos>
(maybe xaa/exa dose too idk)
<uvos>
so if glamor is not in use the windows get renderd at 0 deg
<freemangordon>
again, why then landscape is so slow on pp/d4?
<uvos>
and the ddx has to do something else
<uvos>
no idea
<Wizzup>
so shadowfb didn't seem to matter (much)
<uvos>
someone ahs to trace it
<freemangordon>
I did on d4 and SW rotate path was taken in modesetting
<Wizzup>
this still bothers me: [ 26.151] (II) modeset(0): Disabling kernel dirty updates, not required.
<Wizzup>
also seeing this:
<Wizzup>
[ 26.634] (EE) glamor0: GL error: GL_INVALID_ENUM in glTexParameter(pname=GL_TEXTURE_SWIZZLE_A)
<Wizzup>
(but the GL path worked better then GLES on lima)
<uvos>
so its xf86RotateCrtcRedisplay
<joerg>
freemangordon: yes, in N900 you meant? the "temperature" usually seen is that of the charger chip, not of battery. CPU temperature was considered SiErr broken and not used
<uvos>
and below
<joerg>
the thermistor is supposed to actually measure battery temp but iirc was not exposed in kernel filesystems
<joerg>
you could read it out via ADC iirc
<joerg>
which BME actually did
<uvos>
not reading the cpu temperature at all is kinda flippant :P
<Wizzup>
freemangordon: from my perspective btw I think having pine64 gpu/X behave more would be nice but I don't consider it too urgent, I just wanted to try it out to see if newer glamor and mesa helped, and it probably is less crashy, it didn't solve all the problems
<Wizzup>
so this is not urgent from my perspective, n900 X I think would be more important
<freemangordon>
ok
<freemangordon>
joerg: yeah, and we later on exposed MADC readings through rx51_battery
<freemangordon>
thanks
<Wizzup>
we explicitly disable rx51_battery atm since it's otherwise quite useless
<freemangordon>
wait, why?
<Wizzup>
(and it tells upower we have two batteries)
<freemangordon>
so?
<freemangordon>
a colleague of mine as laptop with 2 batteries
<freemangordon>
*has
<Wizzup>
the n900 doesn't have two batteries
<joerg>
freemangordon: yw
<Wizzup>
maybe it's only for 5.1 btw
<freemangordon>
ok, but rx51_battery provides temp sensor
<freemangordon>
I don't remember what else though
<Wizzup>
we don't have it in 5.15 I think
<freemangordon>
we should
<freemangordon>
otherwise we don;t have sensor
<Wizzup>
I mean we don't have the patch that reverts it
<freemangordon>
ah :)
<Wizzup>
imho though we probably have too many modules loaded making the idle stuff all the harder
<Wizzup>
e.g. the omap3isp stuff also caused trouble
<Wizzup>
and we don't even have anything that uses it yet
<Wizzup>
but that's just a general remark
<freemangordon>
rx51_battery should idle just fine
<Wizzup>
OMAP3_THERMAL for sure dosen't, I spent ~6 hours bisecting it
<Wizzup>
but yeah, we'll see
<freemangordon>
at least on n900 it is useless afaik
<joerg>
my take on this two-battery problem is that the device description (DTS? DTD?) and/or the driver architecture doesn't match the real hardware
<freemangordon>
or rather attempting to put everything in the kernel
<freemangordon>
but yea, we have some general issue here
<freemangordon>
Wizzup: maybe we shall come-up with some 'aggregate' power device kernel framework
<uvos>
we also have the same problem on mz617
<uvos>
it also has 2 battery chips for one battery
<freemangordon>
or, teach upower to handle such cases
<freemangordon>
maybe that'd be easy
<joerg>
pali and me designed rx51_battery(?) module as a foundation for acomprehensive alternative to BME
<freemangordon>
joerg: there is nothing wrong with it
<freemangordon>
it is that upower is not smart enough to know bq and rx51 drivers are about the same physical battery. or we are not smart enough to tell it to :)
<freemangordon>
yeah, 'composite_power' device framework will do the job
<freemangordon>
but I am not the one to implement that :)
<Wizzup>
I think we are smart enough to pick the right device from upower btw
<Wizzup>
it just means that every tool has to be smart enough
<Wizzup>
in any case it's not super important atm
<freemangordon>
yeah
<freemangordon>
Wizzup: later on I will get back to you with glamor patches
<freemangordon>
have to leave now, ttyl
<Wizzup>
ok ttyl
mp1074 has joined #maemo-leste
mp1074 has quit [Client Quit]
System_Error has quit [Ping timeout: 276 seconds]
mp1074 has joined #maemo-leste
<joerg>
>>upower is not smart enough to know bq and rx51 drivers...<< that's pretty much to the point. I think either via device-tree or by driver design, the bq.ko has to become a sub-feature of the *_battery.ko system
System_Error has joined #maemo-leste
<joerg>
I don't know upower but sounds to me like userland, which is not supposed to have prior knowledge about particular hardware properties
<joerg>
'composite_power' device framework sounds great
alex1216 has joined #maemo-leste
uvos has quit [Ping timeout: 240 seconds]
_inky has quit [Ping timeout: 240 seconds]
inky has joined #maemo-leste
inky_ has quit [Ping timeout: 240 seconds]
_inky has joined #maemo-leste
inky_ has joined #maemo-leste
inky has quit [Ping timeout: 256 seconds]
_inky has quit [Remote host closed the connection]
xmn has joined #maemo-leste
inky has joined #maemo-leste
inky_ has quit [Ping timeout: 256 seconds]
_inky has joined #maemo-leste
inky has quit [Remote host closed the connection]
inky has joined #maemo-leste
zhxt has quit [Ping timeout: 256 seconds]
inky has quit [Ping timeout: 240 seconds]
_inky has quit [Ping timeout: 240 seconds]
inky has joined #maemo-leste
_inky has joined #maemo-leste
<freemangordon>
Wizzup: check your mail
<Wizzup>
ty
<Wizzup>
looks like these should fix the es2 problems I was seeing
<Wizzup>
I'll try them, but I think other problems will persist
<freemangordon>
hopefully
<freemangordon>
yeah
<Wizzup>
it's quite some weirdness in general
<Wizzup>
like many of the animations suddenly return later, I've randomly seen the titlebar texture rotate a bit (like we do with phone rotation)
<Wizzup>
(this is not gles or gl specific)
<freemangordon>
this is with latest mesa?
<Wizzup>
yes
<freemangordon>
we shall open a bug then
<Wizzup>
OpenGL ES profile version string: OpenGL ES 2.0 Mesa 21.2.5
<Wizzup>
OpenGL version string: 2.1 Mesa 21.2.5
<Wizzup>
I bet it's glamor and note modesetting, though
<Wizzup>
or rather, not lima
<freemangordon>
yeah
<freemangordon>
but try with those patches first
<Wizzup>
ok
<Wizzup>
rebuilding with gles forced
<Wizzup>
will let you know in ~30 mins
<freemangordon>
ok
<Wizzup>
btw, the landscape stuff got a -bit- faster with the double shadow thing I feel like
<Wizzup>
maybe it transfers less or something
inky has quit [Remote host closed the connection]
inky_ has joined #maemo-leste
<Wizzup>
that 30 mins estimate was pretty accurate :D
<freemangordon>
:)
<Wizzup>
hm I think the font rendering is still broken for me
<Wizzup>
but the colours look ok
<Wizzup>
other corruption is also still there
<freemangordon>
:(
<Wizzup>
not surprising since it's clearly some damage or buffer mgmt problem
<Wizzup>
like I can see the previous screen icons in various apps
<Wizzup>
like the conversations contacts overview icons, they show through on the side of the view of a single conversation when I screen