LinuxMCE Forums
General => Users => Topic started by: widescreen on August 07, 2009, 05:23:40 pm
-
I solved one problem with my core touchscreen and between my first 8.10 install and the latest 8.10 install update used in my reinstall, there is another issue. Whenever I touch home or make certain other selections, it appends "1" right after thereby sending me to lighting. example, if i select direct dial, the keypad shows up with a 1, if I dial 9....you see 91, dial 8...you 81 etc etc. It has nothing to do with the driver and this was not happening before the latest alpha install. My question is whether this has to do with .xorg settings or should i create a xmodmap, or if this is a error like the one that existed in the prior alpha install with weird characters were showing up? It seems to be happening upon "release", meaning if i hold my finger it stay on the main menu. Once i move my finger off, it's like pressing 1 in the keyboard. I works perfectly on the kubuntu desktop, no errors there. thanx ;D
-
shit.. it looks like my GenericHIDInterface driver is causing little glitches by overzealously translating event packets.
-Thom
-
damn, i was hoping it was something i did wrong :P
-
Thom, is there a work around for this for the time being by any chance? 8)
-
Hijacking this thread- there may also be issues with touch pads. Whenever I try to drag the cursor, whenever I release it thinks that I've clicked in the upper left hand corner of the screen on the "lighting" button. By using a USB mouse, this effect is not seen. Maybe related?
-
that is the same issue i'm referring to. It isn't that it's clicking on the upper left hand corner. It is appending the number one to the release of every selection, thereby bringing up the lighting screen making touchscreens unusable.
-
you wanna fix it? install orbiter properly on a device, or get a WebDT from tkmedia.
Otherwise, I'll have to fx the GenericHIDInterface class when I can.
-Thom
-
you wanna fix it? install orbiter properly on a device, or get a WebDT from tkmedia.
Otherwise, I'll have to fx the GenericHIDInterface class when I can.
-Thom
oooo..kay, That's what i was asking. sorry if it sounded a way, i know your busy, that's why i asked of there was a work around because i didnt want to bug you. Maybe i'm a little slow, what do mean install it properly? Not sure what i have done wrong. I have 8.10 installed as a core with a touchscreen, i assume you mean that's no good?
-
Actually I'm glad that Thom said that- got me thinking- the problem doesn't exist for me on any of the orbiters- the one I got from TKmedia, the win orbiter, etc, the problem only seems to appear when I'm using a MD with a touchpad. Widescreen, can you confirm?
-
that IS where the problem is. It comes from the fact that your touchscreen is an HID device. It uses the /dev/input subsystem to communicate. I intercept those packets and translate them.
-Thom
-
Actually I'm glad that Thom said that- got me thinking- the problem doesn't exist for me on any of the orbiters- the one I got from TKmedia, the win orbiter, etc, the problem only seems to appear when I'm using a MD with a touchpad. Widescreen, can you confirm?
no I can't, because i do not have any other touchscreen devices. ;)
-
Not to beat a dead horse, but do the webdt's not use the /dev/input subsystem? And, my win orbiter is on a laptop, but maybe there aren't problems with it due to the OS differences...
-
No, it doesn't. Please ... stop... asking... stupid...questions! You are wasting my time.
-Thom
-
Thom - these aren't stupid questions, please keep the tone friendly!!
-
hello fellas, it sucks but i can now confirm this issue as well, has anyone found a solution besides just not using the touchscreen? thanks :)
-
tschak: if this is really a regression, it has to be fixed asap. We can't trash existing stuff with new patches. And just as a note, that hid stuff should not really be handled in orbiter.
br, Hari
-
tschak: if this is really a regression, it has to be fixed asap. We can't trash existing stuff with new patches. And just as a note, that hid stuff should not really be handled in orbiter.
br, Hari
Hari,to answer your question, it is definitely a regression, Everything was working great until i updated to the later alpha. thanks
-
This has been fixed, and should be available once the next round of updates is built. \
-Thom
-
thanks tschak!!
-
yeah thanks tom, appreciate it
-
This has been fixed, and should be available once the next round of updates is built. \
-Thom
Thom, ahey buddy, has this fix been rolled in? i rebuilt my core and did a reinstall last night and was excited, tried to use my md, but the same issues still occur. ???
-
I don't believe the next round of updates have been built yet.
-
oh ok thanks
-
I don't believe the next round of updates have been built yet.
can anybody confirm this because i see this in the alpha 2.32 release:
pluto-orbiter (119,138) - Fixes to GenericHIDInterface for Gyration 3101 remotes.
is that anything to do with it?
-
fellas, i'm not trying to be a pest, i'm just not sure....so has it been added to the updates already? if so it still does not work
-
hey guys, my experience as of today is as follows:
1) any selection is still being appended with a 1, thereby bringing you to the lighting menu
2)it has gotten worse. the curser does not follow most selections now. before today it would follow wherever you touch. Before you were able to use the touchscreen on the kubuntu desktop. it worked perfectly. now the cursor does not follow where you touch on there too. works fine booting kubuntu from harddrive without lmce, so it's a problem with lmce.
3) all my md hardware is unusable because of this, spent alot of money when it did work, now all is just a waste of money.
4) like hari said, this a regression. :(
-
I can't get anybody to even respond to my questions and comfirm, thom or otherwise as to the status of the fix.
-
apparently, there still is more to do, nevermind that you guys are using a setup i can't reproduce. *hmm*
-Thom
-
apparently, there still is more to do, nevermind that you guys are using a setup i can't reproduce. *hmm*
-Thom
Thom, i understand, and i appreciate you responding to my post. I appreciate your attempt to repair the driver. Hope you understand where we're coming from from, it's a little frustrating to have something working one day, and spending alot of money to purchase more hardware that was proven compatible, to only have your entire setup made useless the next day because of an error i did not make, nor have the equip to fix. please do not take my anxiety any way. 8)
-
apparently, there still is more to do, nevermind that you guys are using a setup i can't reproduce. *hmm*
I can't see anything special in the way those guys use their touchscreens, or do I miss something?
best regards,
hari
-
it comes down to the fact that I decode and send everything that comes across the input subsystem. I need to find a better way to filter spurious events.
-Thom
-
...
Hope you understand where we're coming from from, it's a little frustrating to have something working one day, and spending alot of money to purchase more hardware that was proven compatible, to only have your entire setup made useless the next day because of an error i did not make, nor have the equip to fix.
...
The error is all yours, if only just for using alpha software in a production environment. Yes this needs to be fixed, but simply saying that you made no error is bullshit.
-
tschak: if this is really a regression, it has to be fixed asap. We can't trash existing stuff with new patches. And just as a note, that hid stuff should not really be handled in orbiter.
br, Hari
Zaerc, i tend to agree with the statement above. i can't understand why you would even jump in here and not have anything beneficial to say. I am aware that it is alpha, but does it really makes sense to say my statement is bullshit, taking into account it was working up until a recent update? i could understand you saying that if i was expecting a new feature or something that has been broken prior to a recent update. so how is the error all mine? come on dude, i was only making sure that thom didn't take offense to my posts because no disrespect was intended. read the post, i even thanked him for his help in trying to fix it back. Thom, once again, thanks. zaerc, take it easy
-
...
Hope you understand where we're coming from from, it's a little frustrating to have something working one day, and spending alot of money to purchase more hardware that was proven compatible, to only have your entire setup made useless the next day because of an error i did not make, nor have the equip to fix.
...
The error is all yours, if only just for using alpha software in a production environment. Yes this needs to be fixed, but simply saying that you made no error is bullshit.
Everyone is being told regularily to install 0810 and that 0710 is no longer supported. These 2 posts specifically come to mind:
http://forum.linuxmce.org/index.php?topic=8689.msg58754#msg58754
http://forum.linuxmce.org/index.php?topic=8568.msg57650#msg57650
Seems to me that someone testing your alpha software has found a bug that may not have been found otherwise. How is this the users error?
The more you insult your userbase the less people want to contribute.
J.
-
Zaerc, Thom, Phenigma & Widescreen.....
cool it please! drop the argument at this point, and stay on thread....
of course this is an issue, and naturally it needs to be fixed.... I'm quite certain that thom will get on to it when he has a chance, he is very busy. We are in an unfortunate, sticky situation.... 0710 is no longer supported (and cannot be, realistically) however 0810 is still in Alpha... please be mindful of what alpha means, even though it is really the only "supported" version available at the moment.
Things will improve, and thom will fix this in due course. In the meantime, lets impassionately report the symptoms. Thom is obviously not experiencing the same issue, so any further data will help him lock it down.
Thom - perhaps there is a simple way in which they can capture the HID stream and send it to you so that you can see the issue occurring and adjust your filtering??
-
grepping for GenericHIDInterface in the Orbiter log should be sufficient.
-Thom
-
ok, guys, do you know how to do this? Find your orbiter log file by looking up its device number in the web admin, then:
grep -i generichidinterface /var/log/pluto/##_LaunchOrbiter.sh.log
where ## is the device number
-
i typically tail it.
-Thom
-
bb90>
01 09/16/09 17:13:09.761 GenericHIDInterface::DecodeEventInFD: Short read from fd 1 <0xb3c6bb90>
01 09/16/09 17:13:13.765 GenericHIDInterface::DecodeEventInFD: Short read from fd 1 <0xb3c6bb90>
01 09/16/09 17:13:17.765 GenericHIDInterface::DecodeEventInFD: Short read from fd 1 <0xb3c6bb90>
01 09/16/09 17:13:21.765 GenericHIDInterface::DecodeEventInFD: Short read from fd 1 <0xb3c6bb90>
01 09/16/09 17:13:25.765 GenericHIDInterface::DecodeEventInFD: Short read from fd 1 <0xb3c6bb90>
01 09/16/09 17:13:29.765 GenericHIDInterface::DecodeEventInFD: Short read from fd 1 <0xb3c6bb90>
01 09/16/09 17:13:33.765 GenericHIDInterface::DecodeEventInFD: Short read from fd 1 <0xb3c6bb90>
01 09/16/09 17:13:37.765 GenericHIDInterface::DecodeEventInFD: Short read from fd 1 <0xb3c6bb90>
device number is 31, got error message grep: /var/log/pluto/31_LaunchOrbiter.sh.log: No such file or directory. pulled up above log using grep -i generichidinterface /var/log/pluto/21_LaunchOrbiter.sh.log. 21_LaunchOrbiter.sh.log being the only log under that directory. Also pulled up the log on the md itself, but it had no mention of genericHIDInterface. pretty sure that the above is not what is needed, but that all that seems to come up remotely close to the request. let me know where to find the correct log if so. thanks alot guys. I appreciate the help big time fellas. thanks again.
-
you should not see a short read at all. did you remove an input device?
-Thom
-
you should not see a short read at all. did you remove an input device?
-Thom
thom, nope buddy. i only don't leave the mds on since i don't use it since the problem began. maybe wrong dir/log i'm looking into? :-\
-
short reads happen when the handler tries to read from a device that is no longer there...hmm..
do you not see DecodeEventinFD messages?
-Thom
-
short reads happen when the handler tries to read from a device that is no longer there...hmm..
do you not see DecodeEventinFD messages?
-Thom
yes, could that be due to the removal of another md days ago? should i post sections of the whole log to give you a better idea of what is happening?
-
here is the log from the md
== ATTEMPT FRESH START ==
1 09/11/09 10:04:38 /usr/pluto/bin/Spawn_Device.sh 33 (spawning-device) [1;00m25394 Dev: 33; Already Running list: 32,[1;00m
== FRESH START ==
1 09/11/09 10:04:39 /usr/pluto/bin/Spawn_Device.sh 33 (spawning-device) [1;00mdevice: 33 ip: dcerouter cmd_line: LaunchOrbiter.sh[1;00m
0 09/11/09 10:04:39 33 (spawning-device) [1;00mEntering 33[1;00m
========== NEW LOG SECTION ==========
1 09/11/09 10:04:39 33 (spawning-device) [1;00mStarting... 1[1;00m
1 09/11/09 10:04:39 33 (spawning-device) [1;00mFound /usr/pluto/bin/LaunchOrbiter.sh[1;00m
05 09/11/09 10:11:14.597 [33;1mXlib: ErrorHandler_Grabber() [0m[32m// static int X11wrapper::ErrorHandler_Grabber(Display*, XErrorEvent*)[0m[0m <0xb70ec8e0>
05 09/11/09 10:11:14.634 [33;1mXlib: ErrorHandler_Grabber() [0m[32m// static int X11wrapper::ErrorHandler_Grabber(Display*, XErrorEvent*)[0m[0m <0xb70ec8e0>
-
========== NEW LOG SECTION ==========
1 09/17/09 23:17:52 33 (spawning-device) [1;00mStarting... 2[1;00m
1 09/17/09 23:17:52 33 (spawning-device) [1;00mFound /usr/pluto/bin/LaunchOrbiter.sh[1;00m
05 09/17/09 23:17:54.829 [33;1mCreating child 34[0m <0xb6fa48e0>
05 09/17/09 23:17:54.881 [33;1mCreating child 36[0m <0xb6fa48e0>
05 09/17/09 23:17:54.935 [33;1mCreating child 37[0m <0xb6fa48e0>
05 09/17/09 23:17:54.993 [33;1mCreating child 38[0m <0xb6fa48e0>
05 09/17/09 23:17:55.056 [33;1mCreating child 39[0m <0xb6fa48e0>
08 09/17/09 23:20:15.885 Orbiter::AcquireGrid orbiter grid pnp_33 max row 5 max col 3 cur row 0 cur col 0 <0xb6f63b90>
08 09/17/09 23:20:15.887 acquiring 4482.0.0.4484.2410 <0xb6f63b90>
08 09/17/09 23:20:15.889 Orbiter::AcquireGrid orbiter grid pnp_33 max row 5 max col 3 cur row 0 cur col 0 <0xb6f63b90>
05 09/17/09 23:20:15.891 [33;1mDataGridRenderer::RenderObject Need to render cell <0,0>=Internal HDD, cell count 1[0m <0xb6f63b90>
08 09/17/09 23:20:16.183 Orbiter::AcquireGrid orbiter grid pnp_33 max row 5 max col 3 cur row 0 cur col 0 <0xb6f63b90>
08 09/17/09 23:20:16.183 Orbiter::AcquireGrid orbiter grid pnp_33 max row 5 max col 3 cur row 0 cur col 0 <0xb6f63b90>
05 09/17/09 23:20:16.184 [33;1mDataGridRenderer::RenderObject Need to render cell <0,0>=Internal HDD, cell count 1[0m <0xb6f63b90>
08 09/17/09 23:20:18.478 Orbiter::AcquireGrid orbiter grid pnp_33 max row 5 max col 3 cur row 0 cur col 0 <0xb6f63b90>
08 09/17/09 23:20:18.478 Orbiter::AcquireGrid orbiter grid pnp_33 max row 5 max col 3 cur row 0 cur col 0 <0xb6f63b90>
05 09/17/09 23:20:18.479 [33;1mDataGridRenderer::RenderObject Need to render cell <0,0>=Internal HDD, cell count 1[0m <0xb6f63b90>
08 09/17/09 23:22:16.519 Orbiter::AcquireGrid orbiter grid pnp_33 max row 5 max col 3 cur row 0 cur col 0 <0xb6f63b90>
08 09/17/09 23:22:16.519 Orbiter::AcquireGrid orbiter grid pnp_33 max row 5 max col 3 cur row 0 cur col 0 <0xb6f63b90>
05 09/17/09 23:22:16.520 [33;1mDataGridRenderer::RenderObject Need to render cell <0,0>=Internal HDD, cell count 1[0m <0xb6f63b90>
08 09/17/09 23:22:16.881 Orbiter::AcquireGrid orbiter grid pnp_33 max row 5 max col 3 cur row 0 cur col 0 <0xb6f63b90>
08 09/17/09 23:22:16.881 acquiring 4482.0.0.4484.2410 <0xb6f63b90>
08 09/17/09 23:22:16.884 Orbiter::AcquireGrid orbiter grid pnp_33 max row 5 max col 3 cur row 0 cur col 0 <0xb6f63b90>
05 09/17/09 23:22:16.886 [33;1mDataGridRenderer::RenderObject Need to render cell <0,0>=Internal HDD, cell count 1[0m <0xb6f63b90>
08 09/17/09 23:22:17.152 Orbiter::AcquireGrid orbiter grid pnp_33 max row 5 max col 3 cur row 0 cur col 0 <0xb6f63b90>
08 09/17/09 23:22:17.152 Orbiter::AcquireGrid orbiter grid pnp_33 max row 5 max col 3 cur row 0 cur col 0 <0xb6f63b90>
05 09/17/09 23:22:17.153 [33;1mDataGridRenderer::RenderObject Need to render cell <0,0>=Internal HDD, cell count 1[0m <0xb6f63b90>
08 09/17/09 23:22:19.408 Orbiter::AcquireGrid orbiter grid pnp_33 max row 5 max col 3 cur row 0 cur col 0 <0xb6f63b90>
08 09/17/09 23:22:19.408 Orbiter::AcquireGrid orbiter grid pnp_33 max row 5 max col 3 cur row 0 cur col 0 <0xb6f63b90>
05 09/17/09 23:22:19.409 [33;1mDataGridRenderer::RenderObject Need to render cell <0,0>=Internal HDD, cell count 1[0m <0xb6f63b90>
05 09/17/09 23:22:47.459 [33;1mEvent type 1[0m <0xb6fa48e0>
05 09/17/09 23:22:47.460 [33;1mEvent type 1[0m <0xb6fa48e0>
-
...
Hope you understand where we're coming from from, it's a little frustrating to have something working one day, and spending alot of money to purchase more hardware that was proven compatible, to only have your entire setup made useless the next day because of an error i did not make, nor have the equip to fix.
...
The error is all yours, if only just for using alpha software in a production environment. Yes this needs to be fixed, but simply saying that you made no error is bullshit.
Everyone is being told regularily to install 0810 and that 0710 is no longer supported. These 2 posts specifically come to mind:
http://forum.linuxmce.org/index.php?topic=8689.msg58754#msg58754
http://forum.linuxmce.org/index.php?topic=8568.msg57650#msg57650
Some people with specific issues/wishes that are never going to be addressed in 0710 is hardly "everyone".
Seems to me that someone testing your alpha software has found a bug that may not have been found otherwise. How is this the users error?
Using alpha grade software and expecting it to be perfectly stable is a huge error. You simply cannot make an omelet without breaking eggs. And somehow "to only have your entire setup made useless the next day because of an error i did not make" does not sound like "testing" to me at all.
The more you insult your userbase the less people want to contribute.
J.
What perceived "insult" are we talking about here exactly? Unfounded slanderous statements like that (especially coming from people like you who haven't made any significant contribution at all) really make me wish I never bothered to build and release the alphas in the first place.
-
I've heard "just use 0810" so many times I even stopped counting. Yes, we have too few devs to continue to support 0710, and 0810 is not yet finished. But this was a regression caused by a bounty for the gyration support. Long after we basically did a feature freeze. So let's take care of the affected ppl here and stop offtopic flamewars.
best regards,
Hari
-
If it helps, I can provide my log as well. I quit using this MD (Dell Latitude D800) because I was having problems getting media to play. Whenever I use the touchpad the "lights" menu pulls up- regardless of where I drop the cursor or try to select. I do NOT see this problem when I plug in a USB mouse and use that to control the MD.
Here is part of my log that, like widescreen, I only have a 21_LaunchOrbiter.sh.log, but I have variations of this log (*.log.1, *.log.2.gz, *log.3.gz, ect up to 21_LaunchOrbiter.sh.log.7.gz).
01 09/17/09 19:25:49.502 GenericHIDInterface::DecodeEventInFD: Short read from fd 1 <0xb4787b90>
01 09/17/09 19:25:53.501 GenericHIDInterface::DecodeEventInFD: Short read from fd 1 <0xb4787b90>
01 09/17/09 19:25:57.506 GenericHIDInterface::DecodeEventInFD: Short read from fd 1 <0xb4787b90>
01 09/17/09 19:26:01.506 GenericHIDInterface::DecodeEventInFD: Short read from fd 1 <0xb4787b90>
01 09/17/09 19:26:05.506 GenericHIDInterface::DecodeEventInFD: Short read from fd 1 <0xb4787b90>
01 09/17/09 19:26:09.510 GenericHIDInterface::DecodeEventInFD: Short read from fd 1 <0xb4787b90>
01 09/17/09 19:26:13.510 GenericHIDInterface::DecodeEventInFD: Short read from fd 1 <0xb4787b90>
01 09/17/09 19:26:17.513 GenericHIDInterface::DecodeEventInFD: Short read from fd 1 <0xb4787b90>
01 09/17/09 19:26:21.513 GenericHIDInterface::DecodeEventInFD: Short read from fd 1 <0xb4787b90>
01 09/17/09 19:26:25.518 GenericHIDInterface::DecodeEventInFD: Short read from fd 1 <0xb4787b90>
01 09/17/09 19:26:29.514 GenericHIDInterface::DecodeEventInFD: Short read from fd 1 <0xb4787b90>
01 09/17/09 19:26:33.514 GenericHIDInterface::DecodeEventInFD: Short read from fd 1 <0xb4787b90>
01 09/17/09 19:26:37.514 GenericHIDInterface::DecodeEventInFD: Short read from fd 1 <0xb4787b90>
01 09/17/09 19:26:41.513 GenericHIDInterface::DecodeEventInFD: Short read from fd 1 <0xb4787b90>
01 09/17/09 19:26:45.514 GenericHIDInterface::DecodeEventInFD: Short read from fd 1 <0xb4787b90>
01 09/17/09 19:26:49.514 GenericHIDInterface::DecodeEventInFD: Short read from fd 1 <0xb4787b90>
01 09/17/09 19:26:53.518 GenericHIDInterface::DecodeEventInFD: Short read from fd 1 <0xb4787b90>
I have added/removed/changed various things over the last couple weeks since my last rebuild. I am using putty to get the above log and from what is displayed from the log every 4 seconds on 09/13/09 I got a short ready ending at time-stamp 22:00:39.611. The only thing that I have that would occur around that time is to turn off my lamppost (zwave controlled). Then on 09/17/09 at 19:22:41.195 and occuring again every 4 seconds until 09/17/09 at 19:26:53.518 (approximately 4 minutes?!?) the log ends.
I have my zwave turn on my lamppost at sunset and turn off at 10:00 PM (CST).
Unfortunately I'm running 4-5 MDs at any given time plus the core and turning them on/off trying to get the PXE power on/off to work...
Let me know if I can provide anything else to assist.
-
Any time you remove an input device while the orbiter is running, you will get a short read. Restarting Orbiter will cause the message to stop.
-Thom
-
I just reboot the MD without changing anything else and greping the log, I got this:
01 09/18/09 23:23:09.628 GenericHIDInterface::DecodeEventInFD: Short read from fd 1 <0xb4877b90>
01 09/18/09 23:23:13.628 GenericHIDInterface::DecodeEventInFD: Short read from fd 1 <0xb4877b90>
01 09/18/09 23:23:17.628 GenericHIDInterface::DecodeEventInFD: Short read from fd 1 <0xb4877b90>
01 09/18/09 23:23:21.628 GenericHIDInterface::DecodeEventInFD: Short read from fd 1 <0xb4877b90>
01 09/18/09 23:23:25.628 GenericHIDInterface::DecodeEventInFD: Short read from fd 1 <0xb4877b90>
01 09/18/09 23:23:29.628 GenericHIDInterface::DecodeEventInFD: Short read from fd 1 <0xb4877b90>
Odd thing is that on the restart I got the "You have recently added or removed devices...." so I clicked yes to reboot and was prompted to regenerate all orbiters... it's doing that now.
-
Zaerc, Thom, Phenigma & Widescreen.....
cool it please! drop the argument at this point, and stay on thread....
of course this is an issue, and naturally it needs to be fixed.... I'm quite certain that thom will get on to it when he has a chance, he is very busy. We are in an unfortunate, sticky situation.... 0710 is no longer supported (and cannot be, realistically) however 0810 is still in Alpha... please be mindful of what alpha means, even though it is really the only "supported" version available at the moment.
Hmmm... ok this is a little 'off topic' but I need to respond to the state that "0710 is no longer supported (and cannot be, realistically)"...Colin you 100% right that people here on this Forum are being pushed to use the 0810-alpha in many different threads. However CHT still support & sell Dianemo/Cascade and these are both based on 0710...with very few exceptions we have no significant issues doing so. The decision to not support 0710 was taken....but it was possibly taken in haste as it is certainly practical to do so.
Both Dianemo & Cascade will be upgraded in the new year to a version based on 0910.
All the best
Andrew
-
Andrew,
The reason we took the decision to no longer support 0710, is that it IS not possible to maintain a community process for what has become in essence two different systems.
You do not have the same problems we do. You TIGHTLY control your system's software compliment, and fail to mention that to people reading this thread.
0710 had an upgrade system that was unrealistic to support because it simply took over and diverted the entire dpkg system for its own needs. When your user base is possibly modifying their system adding packages for their own use, this becomes a dangerous issue. But you know this, already! This was discussed at length when we took over.
We also had to make some hard decisions relating to sqlCVS. There were a lot of unanswered questions as to what changes aaron.b had made to sqlCVS post 0710's release. We did not know about MCV, nor about many of the other things that would come to light from investigation in the coming months, so we had to dig down, and learn the ENTIRE build system ourselves, I thank Zaerc for rolling the ball on this one as long as he did, because he got us to the point where we could actually do the real work, but I digress...
We had to fork the code base, and the sqlCVS master so that we could move forward, learn the entire system, and keep moving forward on porting this thing, while improving the system. Once we completely disabled the update mechanisms, and made the system upgradeable via upstream packages for core things (again, thanks to Zaerc and posde), we decided to make this branch of code the HEAD after this release. The port to 0910 will be much faster, now that we know what is going on.
Also, you mention this is not that big of a deal. It's not, but we had to learn the whole process, across every platform. It ISN'T a big deal for you, because uplink works for you. For those who don't know, uplink is Radu Cristecu, who formerly worked on both PlutoHome and LinuxMCE. We don't have ex-employees to help us through the rough spots.
-Thom
-
[..]The decision to not support 0710 was taken....but it was possibly taken in haste as it is certainly practical to do so.
Well, we only have so many people doing things. And the core team has enough on their hands with moving forward, so we can't support 710
Both Dianemo & Cascade will be upgraded in the new year to a version based on 0910.
Well, this is LinuxMCE, not Cascade. And yes, as I have pointed out on numerous occasion, the 810 release part is the hardest, 910 will be much easier. And faster.
-
and, Andrew, just to clarify, by "support" I am referring to - providing updates, patches, changes, etc rather than supporting people using 0710 as is. I continue to provide support for the as-is version of 0710 to whoever wants is (I haven't got 0810, so 0710 is all that I can support!) But it is a statement of fact that 0710 isn't realistically supportable in terms of ongoing development as it is a completely different system requiring a completely different dev environment and all the devs have 0810 dev environment and are working on that system now. It simply isn't practical still to have an old 0710 dev env running and being actively maintained when 1) 0710 as-is is a perfectly good point in time product for people to continue using if they wish, and 2) the 0810/beta is taking so long to get out due to lack of resources.
I realise that Dianemo is using 0710 still, and very successfully, but that is a different subject.
-
If it helps, I can provide my log as well.
...
Let me know if I can provide anything else to assist.
Back to this... anything I can provide to assist?
-
good evening,
i intended on posting my logs, but my log is similiar to what has been posted. just wanted to notify all parties concerned. let me know if anything else can help. thanks
-
Andrew,
The reason we took the decision to no longer support 0710, is that it IS not possible to maintain a community process for what has become in essence two different systems.
You do not have the same problems we do. You TIGHTLY control your system's software compliment, and fail to mention that to people reading this thread.
0710 had an upgrade system that was unrealistic to support because it simply took over and diverted the entire dpkg system for its own needs. When your user base is possibly modifying their system adding packages for their own use, this becomes a dangerous issue. But you know this, already! This was discussed at length when we took over.
We also had to make some hard decisions relating to sqlCVS. There were a lot of unanswered questions as to what changes aaron.b had made to sqlCVS post 0710's release. We did not know about MCV, nor about many of the other things that would come to light from investigation in the coming months, so we had to dig down, and learn the ENTIRE build system ourselves, I thank Zaerc for rolling the ball on this one as long as he did, because he got us to the point where we could actually do the real work, but I digress...
We had to fork the code base, and the sqlCVS master so that we could move forward, learn the entire system, and keep moving forward on porting this thing, while improving the system. Once we completely disabled the update mechanisms, and made the system upgradeable via upstream packages for core things (again, thanks to Zaerc and posde), we decided to make this branch of code the HEAD after this release. The port to 0910 will be much faster, now that we know what is going on.
Also, you mention this is not that big of a deal. It's not, but we had to learn the whole process, across every platform. It ISN'T a big deal for you, because uplink works for you. For those who don't know, uplink is Radu Cristecu, who formerly worked on both PlutoHome and LinuxMCE. We don't have ex-employees to help us through the rough spots.
-Thom
I dont disagree with any of the above at all...and I was certainly not disrespecting any of the above. But we do move code between the two versions (in both directions) and I wanted to make the point that in that sense its possible.
All the best
Andrew
-
I've heard "just use 0810" so many times I even stopped counting. Yes, we have too few devs to continue to support 0710, and 0810 is not yet finished. But this was a regression caused by a bounty for the gyration support. Long after we basically did a feature freeze. So let's take care of the affected ppl here and stop offtopic flamewars.
best regards,
Hari
Good point.
Andrew
-
I've heard "just use 0810" so many times I even stopped counting. Yes, we have too few devs to continue to support 0710, and 0810 is not yet finished. But this was a regression caused by a bounty for the gyration support. Long after we basically did a feature freeze. So let's take care of the affected ppl here and stop offtopic flamewars.
best regards,
Hari
Good point.
Andrew
And yet there are new features in just about every update...
-
I know, i'm sorry, i've stopped adding features.
-Thom
-
Hello, has this problem ever been fixed?
-
Hello, has this problem ever been fixed?
no, I've been checking with every update, no joy. Ironically, I financially contributed to the gyro remote development even though i knew i wasn't going to buy any gyro remotes. But i thought it would be good to give back and say thanks to Thom for all his great work and it was the gyro support that messed up the GenericHiddriver lol. I gave with one hand and slapped myself with the other lol. ;)
-
I can not reproduce the problem here, so I have no way to fix it. No I will not log onto a remote system to fix it, I have bigger bugs to squash.
-Thom
-
i will take another whack at it.
-thom
-
Have you had a chance to whack it yet tschak :)
and if not can we help some how
Chris
-
tschak helped me to overcome this problem!
Symptoms: The touchscreen always brings up the Lighting "More" menu. The problem seems like every touch of the touchscreen clicks in the upper left hand corner.
Problem: The GenericHIDInterface drivers need to be rewritten. Currently, the event packet is being decoded incorrectly, and in fact the touchscreen device shouldn't even be grabbed by the GenericHIDInterface drivers. So let's just remove that functionality from the MD where the touchscreen is installed!
1) Checkout the svn source if you haven't already: svn co http://svn.linuxmce.org/svn/branches/LinuxMCE-0810/src
2) Comment out line 781 from /src/Orbiter/Orbiter.cpp: //pthread_create(&m_GenericHidThreadID, NULL, ProcessGenericHIDEvents, (void*)m_pGenericHIDInterface);
3) Download the libraries necessary to make the Orbiter. I downloaded the following libraries, though I might have more in the list than are necessary:
sudo apt-get install libgtk2.0-dev libxtst6-dev libxtst-dev libxmu-dev libhid-dev libusb-dev libttf-dev libtexttools-dev libsdl-ttf2.0-dev libsdl-gfx1.2-dev libsdl1.2-dev libsdl-image1.2-dev libsdl-sge-dev
4) Copy the files from /usr/pluto/lib into /src/lib (into your svn tree)
sudo cp /usr/pluto/lib/* ../../src/lib/
5) make clean ; make bin
6) Copy the Orbiter binary into /usr/pluto/bin on your MD.
7) Restart your MD.
Thats it! Obviously, this is a workaround and if anyone would like to work on fixing GenericHIDInterface, here's some words from tshack on the topic:
<TSCHAKeee> right now, there is a method in there that just looks for all the event devices in a directory, and grabs them
<TSCHAKeee> this needs to be changed to only grab the devices a template specifies.
<TSCHAKeee> this would solve the problem.
<TSCHAKeee> it doesn't exist
<TSCHAKeee> it would need to be specified i.e.
<TSCHAKeee> /dev/input/by-id/usb-Gyration_Gyration_RF_Technology_Receiver-event-mouse
<TSCHAKeee> with the ability to specify more of them by separating them with something like a |
-
I know this post is going to piss off at least one person but...
TSCHAK was *PAID* for this work (and paid well). Shouldn't TSCHAK fix it rather than pawning it off on someone else? Why should others have to do the work that TSCHAK was paid for?
J.
-
phenigma,
It did what it was supposed to do regarding the 3101 support. It caused an unforeseen problem with someone else.
I can't get to it at present, he wanted it now. So please, ********* ********** **********
-Thom
Edit: moderation applied by hari, tschak please watch your speech..
-
I know this post is going to piss off at least one person but...
TSCHAK was *PAID* for this work (and paid well). Shouldn't TSCHAK fix it rather than pawning it off on someone else? Why should others have to do the work that TSCHAK was paid for?
J.
This will be fixed, is it in trac already?