<tmlind>
uvos: maybe try setting razr_xt9xx_data te_support = 1 assuming you merged with the pvr hacks and have 7c72e56fd0a2 ("WIP: Forward port of droid4 stock kernel changes to prevent tearing")
<tmlind>
note the te_type in the v3.0.8 stock kernel is different between xt894 and xt910, so some other changes may be needed
uvos__ has joined #maemo-leste
<uvos__>
tmlind: thanks for the lead
<uvos__>
ill try that
<tmlind>
ok
<uvos__>
tmlind: do you happen to come across what the touch buttons are connected to on xt910 in the stock kernel? they arnt on the lcds touch controller so xt910 must have somthing sperate for those
<tmlind>
yeah there's some separate controller, let me check
<uvos__>
really wierd that they did that, the whole point of touch buttons was that its cheap becaue you can just use the display touch controller
<tmlind>
yeah
<tmlind>
i think it might be the drivers/input/misc/cy8c201xx_core.c in the stock kernel
<uvos__>
ok ill take a look
<tmlind>
probably takes less power compared to keeping the lcd controller enabled
<uvos__>
the touch buttons are never active when the display is not in android
<uvos__>
so idk where that helps
<tmlind>
ok
<tmlind>
might be this one in the mainline kernel Documentation/devicetree/bindings/pinctrl/cypress,cy8c95x0.yaml
<tmlind>
or similar
<tmlind>
drivers/input/touchscreen/cy8ctm*.c
<tmlind>
so the mxt touch screen works fine, right?
<uvos__>
tmlind: yeah
<uvos__>
well idk
<uvos__>
it often dosent resigter touches
<uvos__>
but that might also be the display
<uvos__>
it works at least sometimes
<uvos__>
it seams like the display also hangs often
<uvos__>
(see video this happens at the beginning)
<tmlind>
ok maybe different firmware
<tmlind>
embedded in the dts
<uvos__>
maybe or its just the entire device/or display hanging for 1-2 sec
<tmlind>
yeah ok
<uvos__>
not sure its the mx touch controllers fault
<tmlind>
i'm also seeing the sideways jumping with just dd if=/dev/urandom of=/dev/fb0
<tmlind>
sideways as in portrait mode
<uvos__>
ok
<uvos__>
hblank issues :P
<tmlind>
the timings should be the same, well what is used for timings in the command mode case
<tmlind>
as on xt894
<uvos__>
ok, at lesat it looks like hblank not syncing up, could be another cause
<tmlind>
i guess i'll continue on the mz61x bridge stuff when i get a chance
<tmlind>
i mean mz6xx. i need to also figure out why memtester fails on my mz609 while android works happily
<tmlind>
could be some cpcap regulator low level init thingy
<uvos__>
tmlind: that would be neat. im mutch more excited about leste on mz6xx than xt910 (or mb865)
<Wizzup>
freemangordon: will take a look, I didn't look anymore after this weekend
* tmlind
bbl tonight
<uvos__>
ttyl tmlind
pere has quit [Ping timeout: 256 seconds]
<Wizzup>
freemangordon: looks like it likely is a double free yes
<Wizzup>
freemangordon: I see you pushed already
akossh has joined #maemo-leste
<Wizzup>
tmlind: thanks, will try the new kexecboot
<Wizzup>
uvos__: btw I have these, but none have mbm allow flashing: VRZ_7.7.1-85_MZ617-27_CFC_1FF.xml.zip VRZ_9.8.2OT_127_MZ617_CFC_1FF.xml.zip VRZ_MZ617_1.6.0_279_CFC_1FF.xml.zip
<uvos__>
Wizzup: yes i downloaded all mz6xx updates
<uvos__>
none have it
<uvos__>
only the otg updates have
<uvos__>
but bearly anyone saved the otg updates
<Wizzup>
hmm
<Wizzup>
do we have any file hashes?
<uvos__>
i dont think so
<uvos__>
but can look in my notes later
<Wizzup>
cool, I'm heading out first now anyway
<uvos__>
i have never seen a otg update at all
<uvos__>
i only know from xda
<uvos__>
and someone posted the mz607 file there with the comment that it came from otg
<freemangordon>
Wizzup: hmm, why do we need that?
<freemangordon>
(thi issue)
<freemangordon>
*the
<uvos__>
desktop applications are unsable without
<uvos__>
since they tend to have alot of actions
<freemangordon>
uvos__: see the issue
<freemangordon>
it is not about meus
<freemangordon>
*menus
<freemangordon>
also, if we are going to implement stacked menus, I don;t see why we shall do that for qt apps only
<uvos__>
sorry right
norayr has left #maemo-leste [Disconnected: Received SIGTERM]
<uvos__>
freemangordon: because we can for qt
norayr has joined #maemo-leste
<freemangordon>
ok, but IIUC it is the WM that draws menus, no?
norayr has left #maemo-leste [Disconnected: Received SIGTERM]
norayr has joined #maemo-leste
norayr has left #maemo-leste [Disconnected: Received SIGTERM]
norayr has joined #maemo-leste
<uvos__>
sure
<uvos__>
or no
<uvos__>
th application draws the menu
<uvos__>
the wm just places it
<uvos__>
but the point is that the qt definiton of the menu allready contains a hieracy that we are not useing
<uvos__>
while the gtk2 menus are indeed flat
<uvos__>
in gtk2 the menu is formed by the application implementing a custom window and teling the wm that this is the menu
<uvos__>
so only mameo applications do this ofc
<uvos__>
in qt the qmenu is used to generate a window. the qmenu is the same thing that generates the file, edit, help etc buttons in a desktop application
<uvos__>
so all of the regular desktop applications have a maemo menu
<uvos__>
thats great! .. in theroy, in practice it dosent work so well becasue the actions are flattend, Wizzup wants to improve this
<uvos__>
so implementing stacked windows in gtk2 would be possibe, but would be an entirely seperate piece of code and would have no current users
<uvos__>
while stacked windows in qt are instantly usefull and used by various applications
<uvos__>
freemangordon: the qt application featherpad is a good demonstator of how current behavior is undesirable
<uvos__>
run it first the normal way
<uvos__>
and then with -platform xcb
peetah has quit [Quit: -]
peetah has joined #maemo-leste
norayr has left #maemo-leste [Disconnected: Received SIGTERM]
norayr has joined #maemo-leste
ceene has quit [Ping timeout: 252 seconds]
<Wizzup>
freemangordon: this is about menus
<Wizzup>
freemangordon: so for example, when do we render the arrow at the top indicating there is a maemo menu?
<Wizzup>
currently we don't at all, but if I implement it, I have to check (1) if there is a qmenu and (2) if the app wants a menu there
<Wizzup>
qt maemo just hacked it
<Wizzup>
I think we ideally support applications with qmenu but not with hildon menu
<Wizzup>
and applications that want a hidon menu
<Wizzup>
and optionally, later, a way to use hildon menu for nested menus
<Wizzup>
for this we have to know if the app wants to use maemo menus or not
<Wizzup>
for example, currently all 'maemo qt' apps manually "hide" their qmenu
<Wizzup>
like, in C++ code
<uvos__>
if netsted windows work we can presumably just hide the qmenu attached to qmainwindow
<uvos__>
or?
<uvos__>
for everyone
<uvos__>
the arrow is more tricky with qmenu or gtk2 menus used by otherwise qt apps
<Wizzup>
uvos__: ok, I have a xt1602
<Wizzup>
uvos__: if nested menus work you mean?
<uvos__>
nice
<uvos__>
yes
<Wizzup>
I still think we should have an option for using regular menus
<uvos__>
ok like in code or env override?
<Wizzup>
both
<Wizzup>
then we could set the env override by default if we want it for everything eventually
<uvos__>
ok
norayr has left #maemo-leste [Disconnected: Received SIGTERM]
norayr has joined #maemo-leste
norayr has left #maemo-leste [Disconnected: Received SIGTERM]
norayr has joined #maemo-leste
<Wizzup>
pmos doesn't mention ofono for xt1602
norayr has left #maemo-leste [Disconnected: Received SIGTERM]
<Wizzup>
I find it amusing that folks on that page write that the 1GB ram version is 'very slow'