inky_ has quit [Remote host closed the connection]
Wikiwide has quit [Ping timeout: 240 seconds]
Wikiwide_ has joined #maemo-leste
Wikiwide_ is now known as Wikiwide
<calebtheythem[m]>
Wizzup: i saw those listings, I'm worried they have the same issue as mine where the phone works fine but the panel is just broken
<calebtheythem[m]>
the notification led is green in the pictures i saw and from what i can tell that only happens when the phone is booted into Android
joerg has quit [Ping timeout: 264 seconds]
joerg has joined #maemo-leste
mardy has joined #maemo-leste
dsc_ has quit [*.net *.split]
yanu_ has quit [*.net *.split]
yanu has joined #maemo-leste
dsc_ has joined #maemo-leste
jr-logbot has quit [*.net *.split]
r3boot has quit [*.net *.split]
jrayhawk has quit [*.net *.split]
meldrian has quit [*.net *.split]
mrtux has quit [*.net *.split]
r3boot has joined #maemo-leste
meldrian has joined #maemo-leste
meldrian has quit [Changing host]
meldrian has joined #maemo-leste
jr-logbot has joined #maemo-leste
jrayhawk has joined #maemo-leste
<freemangordon>
YAY! no more flickering
System_Error has quit [Ping timeout: 276 seconds]
System_Error has joined #maemo-leste
<tmlind>
freemangordon: nice, look forward to seeing what the fix is :)
<freemangordon>
tmlind: unfortunately it is un userland
<freemangordon>
and is pvr specific
<freemangordon>
so not sure how that can be ported to kernel
<freemangordon>
bu basically, it is calling PVR2DQueryBlitsComplete on the source pixmap BO before requesting page flip
<freemangordon>
maybe we can teach pvr driver to not signal the exclusive fence it attaches to the BO until all write ops are finished
<freemangordon>
but honestly, this is a bit over my knowledge
<tmlind>
heh ok
<tmlind>
hmm so you're thinking about patching drivers/gpu/drm/pvrsgx kernel driver to somehow know until writes are done? is there any way it would even know?
<freemangordon>
pvr driver know
<tmlind>
ok
<freemangordon>
and also it attaches exclusive fence to the BOs it imports
<tmlind>
so pvr driver would know, omapdrm has no clue, right?
<freemangordon>
omapdrm has clue too
<tmlind>
oh
<freemangordon>
but the 'clue' (fence) is misleading ATM
<tmlind>
ok
<freemangordon>
as pvr driver signal that fence too early
<freemangordon>
this is my understanding at least
<freemangordon>
tmlind: have a look at pvr_linux_fence.c
System_Error has quit [Ping timeout: 276 seconds]
System_Error has joined #maemo-leste
<freemangordon>
glmark2 running in h-d window, glmark score 53
<freemangordon>
:)
<tmlind>
nice
<freemangordon>
that should increase, when HW composition is in place
<freemangordon>
but for now is good enough I guess
<tmlind>
yeah and nice to get rid of the old hacks
<freemangordon>
mhm
_inky has quit [Ping timeout: 268 seconds]
inky_ has joined #maemo-leste
System_Error has quit [Remote host closed the connection]
<freemangordon>
ok, lets see if that fixes flickering on n900 too
System_Error has quit [Ping timeout: 276 seconds]
Pali has joined #maemo-leste
<freemangordon>
yes, no flicker :)
<freemangordon>
h-d scrolling fps is a bit low (~30), while modesetting/glamor does ~60, but I guess this is dr3 vs dri2 thing
<freemangordon>
Wizzup: is kernel pakcged for n900 too?
pere has quit [Ping timeout: 256 seconds]
<tmlind>
freemangordon: so is it the sgxMapPixmapBo() that fixes the fence issue? not seeing it paired with sgxUnmapPixmapBo().. i guess i don't follow
<freemangordon>
when you do PVRSRVMapFullDmaBuf on BO, you get 2 things:
<freemangordon>
device address (I think this is the entry in SGX MMU)
<freemangordon>
and PVRSRV_CLIENT_SYNC_INFO structure, which I guess is mmap()-ed kernel memory directly updated by the driver (didn;t look at the details)
<Wizzup>
freemangordon: it might need more work the n900
<Wizzup>
it's probably in the droid4 component of the repos too
<freemangordon>
it seems every time a render task is started, ui32WriteOpsPending is incremented
<freemangordon>
Wizzup: well, ok, but we want same kernel for all omaps, no?
<tmlind>
freemangordon: oh i sort of recall those counters map back to omapdrm
<Wizzup>
freemangordon: yes
<freemangordon>
the stopper was sgx, but now we have it... :)
<freemangordon>
tmlind: really? never seen those
<freemangordon>
maybe some hack?
<freemangordon>
I mean - never seen those in omapdrm
<Wizzup>
freemangordon: yes, agreed
<freemangordon>
so, we only need to find someone to do the job, no? :p
<Wizzup>
just mentioned to component for testing, but it also needs some other changes wrt /boot/ I think
<Wizzup>
yeah I'll work with parazyd
<freemangordon>
great
<Wizzup>
I think:
<Wizzup>
1. kernel headers pkg
<Wizzup>
2. dd pkg
<Wizzup>
ddx
<freemangordon>
will try (1) later on
<Wizzup>
3. test on d4
<Wizzup>
4. make generic and test on n900, bionic
<Wizzup>
right
<Wizzup>
I will work on this today
<tmlind>
freemangordon: i think the pvr driver ops counts map to omapdrm counts in the ddk-1.9 kernel, see the old int sync_op()
<freemangordon>
Wizzup: there are 2 more things to be fixed:
<freemangordon>
1. even on d4 fps is too low, I think video-omap dri2 implementation is kinda lame, it doesn't allow the client to continue rendering until the current buffer is not flipped. or maybe that's how dri2 works, dunno, lets see what uvos has to say about that.
<freemangordon>
2. tklock window is not being updated
<freemangordon>
tmlind: ah, ddk 1.9
<tmlind>
freemangordon: yeah i think both omapdrm and pvr kernel driver tweak the same ops counts..
<freemangordon>
tmlind: but, doing that in 5.15 is not an option, no?
<freemangordon>
so we need an exclusive fence that gets signalled when renering completes
<tmlind>
not sure, i think we may just need to add checking for write_pending to omapdrm to make sure writes have completed?
<freemangordon>
sorry, don;t get that
<freemangordon>
which code in 5.15 do you mean?
<tmlind>
yeah
<freemangordon>
I mean - how omapdrm even knows of such pvr details?
<tmlind>
so in ddk-1.9 kernel patches, to me it seems that struct omap_gem_object is shared between both omapdrm kernel module and pvr kernel module
<freemangordon>
keep in mind omapdrm already supports fences and wait on exclusive if one exists
<tmlind>
both can tweak the usage counts for write_pending and write_complete
<freemangordon>
so definitely it is pvr that has to be fixed
<freemangordon>
IMO
<freemangordon>
anyway, gtg now, meeting, ttyl
<tmlind>
yeh out of here too, ttyl
panzeroceania has quit [Ping timeout: 264 seconds]
nohit has quit [Ping timeout: 268 seconds]
nohit has joined #maemo-leste
panzeroceania has joined #maemo-leste
pere has joined #maemo-leste
<bencoh>
freemangordon: no, sorry (regarding dmafences)
<Wizzup>
freemangordon: right @ things to be fixed
<Wizzup>
freemangordon: do you only need the headers you included (hwdefs and include4), or potentially more
<Wizzup>
this should give us all: find ./drivers/gpu/drm/pvrsgx/1.17.4948957/ -name \*.h -type f -o -type l
<Wizzup>
but that will make it go in /usr/src/linux-headers-5.15.2/include/drivers/gpu/drm/...
_inky has quit [Ping timeout: 245 seconds]
_inky has joined #maemo-leste
<Wizzup>
parazyd: what is the reason we don't just carry the kernel patches in our kernel branches as opposed to in the maemo/beowulf* branches?
<Wizzup>
probably the same question for the 0001-maemo-leste-quirks.patch
<Wizzup>
it is extremely tedious to change anything, since you need to jump back and forth between branches and every time you do there is manual cleanup to be done
<Wizzup>
also the patches are essentially unmaintainable
* bencoh
nods vigorously
inky_ has quit [Ping timeout: 264 seconds]
inky has joined #maemo-leste
<Wizzup>
I don't see why we do it this way, the only thing that it might make easier is rebasing on a new branch, but 'git rebase' should just take care of the problems really
<Wizzup>
omg the patches in debian/series aren't even git-am able :(
<Wizzup>
whoever invented quilt must have done it before git
inky has quit [Ping timeout: 260 seconds]
<Wizzup>
freemangordon: oh yeah for n900 we also want the wifi patch
<Wizzup>
parazyd: also what tags should I use to make you and uvos happy
<Wizzup>
any suggestions for the omap device shared kernel
<Wizzup>
(or perhaps even for all devices?)
<Wizzup>
we could do maemo-kernel or omap-kernel
inky has joined #maemo-leste
<Wizzup>
freemangordon: with my current (not yet in repo) code it ends up here:
<Wizzup>
all of this is much more messy than just the sgx-ddk-um package I have but hey :P
inky has quit [Remote host closed the connection]
<Wizzup>
bencoh: latest kernel should be dpkg-buildpackage -b -uc buildable mostly, just checkout maemo-5.15 and then do parazyd's trick to checkout the debian dir
<Wizzup>
I moved most of the patches (apart from config changes) to git
<bencoh>
neat
<Wizzup>
yeah maybe we just disable quilt alltogether later on
<Wizzup>
parazyd: so any suggestions for the name? either maemo-kernel (if we plan on using it for pine64 as well) or omap-kernel
<Wizzup>
or omap-linux / maemo-linux I suppose
<parazyd>
The pine64 kernel is specific to Pinephone/Pinetab, it's not in general for Allwinner.
<parazyd>
So I'd keep that as "pine64-linux".
<parazyd>
For the PVR kernel, I would go with "omap-linux"
<parazyd>
And finally if we want other generic kernels, just "maemo-linux", yeah.
<parazyd>
Or just "linux" even
<Wizzup>
so I am wondering if we shouldn't aim to have omap-linux be the generic one
<Wizzup>
we'll probably always carry some patches on top, but they should not affect other parts
<parazyd>
I think the issue is we build a package with a specific name from the repo.
<parazyd>
And also a specific arch
<Wizzup>
yes, that's the next thing I wanted to bring up
<parazyd>
Not sure how we can have more than 1
<Wizzup>
what do you mean exactly?
<parazyd>
Building for all these different platforms with a single debian dir
<Wizzup>
right, we'd have to consolidate the package names
<Wizzup>
as in we probably want to get rid of droid4-linux anyway
<Wizzup>
since it's also bionic, droid3, and more
<Wizzup>
and if it's also n900, maybe omap
<parazyd>
Yeah we wanted to rename that to omap-linux
<Wizzup>
but then if we can just use the 5.15 for the pine and others as well, we could just make it maemo-linux
<Wizzup>
was mostly my point
<Wizzup>
I doubt the omap and allwinner patches conflict typically
<bencoh>
you can't really build on the fact that you'll always be able to run the same version on your devices though
<Wizzup>
ok, that argues for omap-linux I guess
<bencoh>
(assuming this fact really plays a part in your decision)
<parazyd>
We can have different branches in the same repo
<parazyd>
But that's not much more beneficial than separate repos
<Wizzup>
saves some bits on hard disks and cloning, but I think it complicates our maemo/* branches
<Wizzup>
no?
<parazyd>
It does
<bencoh>
this will prolly add another layer yeah
<parazyd>
I'll think about it a bit
<Wizzup>
maybe we go for omap-linux for now
<Wizzup>
unrelated, we're getting a HoneyComb LX2 for arm builds
<freemangordon>
Wizzup: do we have pkgconfig for that?
<freemangordon>
(kernel headers)
<Wizzup>
freemangordon: no, not for the new ones, I don't know how to do it for specific kernel versions
<Wizzup>
I had one in sgx-ddk-um but I don't know how to adapt it to path of installed kernel
<freemangordon>
ok, but kernel-headers-dev should have .pc file, no?
<Wizzup>
I don't know of any kernel-headers-dev pkg
<freemangordon>
sorry, kernel-headers or whatever is the name of the package with the headers
<parazyd>
Are you building a kernel module or something else?
<freemangordon>
no, DDX
<Wizzup>
parazyd: no he wants to use the headers in the DDX
<Wizzup>
freemangordon: and no it does not ship with a pc, this is very uncommon I think
<Wizzup>
that's why I copied the headers to sgx-ddk-um
<parazyd>
There's no pkg-config for that
<freemangordon>
can we have sgx-ddk-um depending on a particular kernel-headers version?
<parazyd>
(btw it should be called linux-libc-dev)
<parazyd>
freemangordon: Yes
<Wizzup>
I am against the idea tbh
<freemangordon>
and providing .pc file too
<Wizzup>
I would much rather have sgx-ddm-um use kernel version as versioning
<Wizzup>
and just copy the headers over
<freemangordon>
Wizzup: why?
<Wizzup>
since we're exposing internal kernel driver headers
<Wizzup>
this is never done
<parazyd>
You don't need a .pc file
<freemangordon>
no, those are not internal
<Wizzup>
if you look at normal linux headers they are only for drivers
<parazyd>
They're always in /usr/include/linux
<Wizzup>
DKMS stuff
<freemangordon>
ok, but there are userland interfaces too
<Wizzup>
also, *every* other sgx release we did we had the headers in a separate repo
<Wizzup>
afaik
<freemangordon>
oh, ok :)
<freemangordon>
do it as you think is best.
<Wizzup>
if you have an idea on how we can make the .pc file we can make it work
<Wizzup>
otherwise I would rather have the header files in the sgx-ddk-um pkg
<Wizzup>
but afaik pkgconfig cannot script or use globs in paths
<freemangordon>
what about creating sgx-ddk-um-headers pkg created out of kernel build?
<Wizzup>
(so /usr/src/linux-headers-*/driver/gpu/drm/pvrsgx/... is out of the question
<Wizzup>
)
<freemangordon>
you can create package.pc.in
<Wizzup>
yes, that is potentially possible, but it's quite some work because kernel ships with it's own builddeb script
<freemangordon>
ah
<Wizzup>
yeah... :p
<Wizzup>
I haven't really seen .pc files be shipped from any kernel pkg much either
<freemangordon>
oh, ok then
<freemangordon>
just make sure sgx-ddk-um-dev provides "sgx-ddk-um-1.17.4948957" or somesuch
<Wizzup>
and regarding versioning, shall we postfix it with kernel version?
<Wizzup>
or maybe prefix
<freemangordon>
I don;t think kernel version matters
<freemangordon>
I think it is DDK version that does
<Wizzup>
it will if you end up changing headers
<Wizzup>
as in I was assuming you planned to change the headers
<freemangordon>
no
<Wizzup>
oh
<freemangordon>
what to change there?
<Wizzup>
well, I just assumed you would change them because you wanted them from the kernel
<Wizzup>
*shrug*
<Wizzup>
let me remove the pvr headers from the next kernel build again, and I'll try to tidy up the sgx-ddk-um as you request
<freemangordon>
ok
<Wizzup>
I was already able to build the DDX with it earlier
<Wizzup>
the kernel that is building atm should also work on n900 (although it might not ship with the dtb - we need to fix that)
<freemangordon>
the point is that DDX should depend on sgx -dev package providing headers for a particular DDK version
<Wizzup>
anything else, otherwise I'll take a quick break?
<Wizzup>
ok
<Wizzup>
makes sense
<freemangordon>
but I'll leave that to you and parazyd to agree upon how to do
<Wizzup>
I'll make sure to do that
<freemangordon>
ok
<Wizzup>
I plan to have my droid4 and n900 over to 5.15 by this evening :)
<Wizzup>
at least in experimental
<freemangordon>
Wizzup: btw, did you see that I made n900 flicker go away?
<Wizzup>
I read it yes :-D
<freemangordon>
I need uvos though, I want to discuss with him if it makes sense to implement dri3
<Wizzup>
ok
<freemangordon>
or to fix dri2
<Wizzup>
but I think we can move forward with this, at least for experimental
<Wizzup>
maybe even -devel
<freemangordon>
yeah
<freemangordon>
mind you, still no portrait on n900
<freemangordon>
and it is slower that currently
<freemangordon>
*than
<Wizzup>
*shrug* it's better than 5.1
<Wizzup>
I use the n900 mostly for devel/testing, so I don't mind that so much
<freemangordon>
not sure its better, but it will be :)
<Wizzup>
I think it's better to do the kernel merging now
<freemangordon>
sure
<Wizzup>
it also allows us to toy with OFF mode
<crab>
hi all, i updated my maemo-leste the other day and the gui appears to have died a bit, maybe because it wants ofono? its not a big issue as i mainly use it headless for irc (its lurking in this channel as n900) but if anyone has any suggestions id be grateful. :)
<sicelo>
+1 @ OFF mode.
<Wizzup>
crab: yikes you're the third to report that
<crab>
im just trying another update now so apologies in advance if that fixes it. :)
<Wizzup>
brb sorry, half an hour or so
<crab>
Wizzup: is that bad or good?
<crab>
my installation is a bit crazy so im reluctant to moan too much as it could well be stuff like that!
<crab>
also <smugly>sorry for registering 'n900' for my n900 if anyone wanted to do that, but it had to be done!</smugly>
<sicelo>
btw, although i can't say 100% certainty atm, with 5.15 expect other N900 issues, e.g. non-working RGB LED, etc. But I know why they're like that ... just didn't have time to make proper fixes and send upstream
<Wizzup>
sicelo: what are your fixes?
<Wizzup>
we could include them now
Wikiwide has quit [Ping timeout: 256 seconds]
<Wizzup>
crab: :p
<Wizzup>
actually brb now :)
<sicelo>
turned out to not be a good fix, imo. so the rgb led controller doesn't get turned on at boot or when you probe the module. so i had proposed to have it set on at boot. LED subsystem maintainers (pavel) were willing to accept it.
<sicelo>
it's turned on by GPIO. I wanted to set it always high. later on, someone had a patch where he needed to set it always low :-p
<sicelo>
so yes, that's why i think it needs further tracking
<sicelo>
atm i don't remember the other guy's commit, but he was editing this exact line on the driver
inky has quit [Ping timeout: 264 seconds]
inky has joined #maemo-leste
<sicelo>
so you could take my fix (always set gpio high), with the understanding that a better solution must be found
<sicelo>
anyway also, as said earlier, i haven't played with recent kernels. maybe something has changed already with these drivers and maybe will work correctly ootb now
inky has quit [Ping timeout: 245 seconds]
<Wizzup>
parazyd: we also need to ship/install more dtbs I think
<Wizzup>
parazyd: what section should we use?
<Wizzup>
omap?
<Wizzup>
(and how do we have people upgrade to that)
<Wizzup>
e.g. xf86-video-omap is section droid4
<Wizzup>
freemangordon: what version do you want for the ddx in the changelog
<Wizzup>
0.4.6 or 0.5.0
<Wizzup>
I am assuming 0.5.0
<freemangordon>
yeah
<Wizzup>
before the end of the year we will have a much faster build machine
<Wizzup>
for arm
<Wizzup>
freemangordon: ok, should be in the repo in ~2 mins
<Wizzup>
I guess that's all the components
<Wizzup>
any hint on xorg.conf required?
<Wizzup>
I could try it now on my droid4
<freemangordon>
keep in mind this will still not work on n900
<freemangordon>
but on d4 should be ok
<Wizzup>
ok
<Wizzup>
I pushed to xf86-video-omap
<Wizzup>
I think we might need replacements for some of these: pvr-omap4 pvr-omap4-libs pvr-omap4-utils
<Wizzup>
or, not sure you did you the upgrade
<Wizzup>
can I tell to remove certain packages and install other ones or something?
<Wizzup>
does our mesa not provide libgles1 ?
<Wizzup>
heh hildon-meta-droid4 wants pvr-omap4
<Wizzup>
and cloudgps hard depends on it it seems like
* Wizzup
documents
<Wizzup>
freemangordon: so any xorg.conf stuff I should change, or anything else, before I reboot?
<Wizzup>
/usr/lib/arm-linux-gnueabihf/libglslcompiler.so: /lib/arm-linux-gnueabihf/libm.so.6: version `GLIBC_2.29' not found (required by /usr/lib/arm-linux-gnueabihf/libglslcompiler.so)
<Wizzup>
so I think this still needs the libc treatment
<Wizzup>
I forgot where I had the code to soften those requirements
* Wizzup
break for real
inky has quit [Ping timeout: 245 seconds]
System_Error has joined #maemo-leste
mrtux has joined #maemo-leste
_inky has quit [Ping timeout: 264 seconds]
inky has joined #maemo-leste
<freemangordon>
Wizzup: sorry, I was on a meeting
<freemangordon>
yes, I will push a couple of fixes, one of them being the init fix
<freemangordon>
and yes, as uvos said we have to relax libglslcompiler.so glibc requirement
<freemangordon>
script to do that is on github issue, LMK if you cannot find it, I have the script around
_inky has joined #maemo-leste
<freemangordon>
Wizzup: which branch shall I continue work?
pere has quit [Ping timeout: 245 seconds]
<freemangordon>
Wizzup: sgx-ddk-um-dev should depend on sgx-ddk-um, no?
<freemangordon>
Wizzup: did you push the solution to "undefined symbol: PVRSRVConnect"?
<freemangordon>
Wizzup: going on a walk, ttyl, please push if you gave fix for ^^^
<Wizzup>
freemangordon: hi
<Wizzup>
freemangordon: I need libc fixes only
<Wizzup>
freemangordon: problem with that symbol is stray + in my Makefile.am
<Wizzup>
I have fix here
<freemangordon>
please push it
<Wizzup>
it is on maemo/beowulf-experimental
<freemangordon>
is not, just pulled
<Wizzup>
oh it is not\
<Wizzup>
sry just got back
<Wizzup>
it is now
<freemangordon>
np, take your time
<freemangordon>
ok
<Wizzup>
nah I want to see h-d on my device so I'm happy to prioritise :p