Re: [opensource-dev] 3D connexion devices on linux

[Francesco "Sythos"]

We cannot ask to the world to patch the kernel for SL, not all have enough
skills, and all other device and programs work fine. Imho the right way to
work is fix the SL side, without introduce risk and collateral effect
putting hands on kernel

-- 
Sent by iPhone

Il giorno 04/giu/2011, alle ore 08:59, "L. Christopher Bird" <
zenmo...@gmail.com> ha scritto:

I have a friend that uses a space navigator for SL and explains that it was
broken in the past and SL had a workaround, and by actually fixing the
kernel broke SL.  Here is the patch she wrote. In short just adding a
"return" in the right place.

diff -ru linux-2.6.36-gentoo-r5/drivers/hid/hid-lg.c
linux-2.6.36-gentoo-r5-new/drivers/hid/hid-lg.c
--- linux-2.6.36-gentoo-r5/drivers/hid/hid-lg.c 2010-10-20
16:30:22.0 -0400
+++ linux-2.6.36-gentoo-r5-new/drivers/hid/hid-lg.c 2011-03-09
20:44:53.0 -0500
@@ -53,6 +53,7 @@
rdesc[84] = rdesc[89] = 0x4d;
rdesc[85] = rdesc[90] = 0x10;
}
+   return; // A cheap hack to make SL work.
if ((quirks & LG_RDESC_REL_ABS) && rsize >= 50 &&
rdesc[32] == 0x81 && rdesc[33] == 0x06 &&
rdesc[49] == 0x81 && rdesc[50] == 0x06) {

-- Zen

On Fri, Jun 3, 2011 at 6:03 PM, Altair Sythos  wrote:

> linux resident with kernel 2.6.35 (or more) cannot use 3d mouse bc
> NDOF0.2 don't support new "evdev" interface, NDOF 0.3 (released by same
> author of previous one) support fine both old and new kernels, how can
> somebody submit via HG or else the new code?
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] new subtasks added to STORM-312 (was: 3D connexion devices on linux)

[Boroondas Gupte]

On 06/04/2011 10:37 AM, Francesco "Sythos" wrote:
> We cannot ask to the world to patch the kernel for SL, not all have
> enough skills, and all other device and programs work fine. Imho the
> right way to work is fix the SL side, without introduce risk and
> collateral effect putting hands on kernel
Yes, patching the kernel is a workaround, not the solution. The kernel
has changed its interface for a reason and linux libNDOFdev must go with
it (and /has/ already gone with it. We just need to upgrade to Jan's
latest version, 0.3.)

The upgrade could easily be done by one of us community devs if the 3p-*
repository to create the current linux libndofdev autobuild installable
would be around. Note that the already published
https://bitbucket.org/lindenlab/3p-libndofdev is a different library
(the one for Mac and Windows by 3DConnexions, now hosted by LL).

Thus I've created two subtasks on STORM-312
:

* STORM-1319  for
  publishing the 3p-* repo with the currently used (0.2 based) code
* STORM-1320  for
  upgrading it to Jan's version 0.3

I'm willing to take up STORM-1320
 once STORM-1319
 is done.

@Oz: Can you please investigate (or get someone to investigate) whether
a 3p-* repo for the linux libNDOFdev already exists internally at LL and
can be published? If none exists, yet, and we thus have to create one
for Jan's sources from scratch, I'd like someone to walk me through the
process of doing so. (Yes, I know there are guides about that on the
wiki, but I don't even know which of the apparently several ones to follow.)

Cheers,
Boroondas

PS: For a history of this issue, also see the duplicate at OPEN-21
.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] new subtasks added to STORM-312 (was: 3D connexion devices on linux)

[Sythos]

On Sat, 04 Jun 2011 13:00:38 +0200
Boroondas Gupte  wrote:


> @Oz: Can you please investigate (or get someone to investigate)
> whether a 3p-* repo for the linux libNDOFdev already exists
> internally at LL and can be published? If none exists, yet, and we
> thus have to create one for Jan's sources from scratch, I'd like
> someone to walk me through the process of doing so. (Yes, I know
> there are guides about that on the wiki, but I don't even know which
> of the apparently several ones to follow.)

agree a lot, i've already a 3p-ndof (used by me for KV purposes)m i
should just clean around replacing KV with LL :)
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: patch to let 3D connexion devices work on linux with kernel 2.6.35 or newer

[Boroondas Gupte]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/322/#review717
---



autobuild.xml


I don't think the LL viewer should use library binaries not hosted under 
LL's control.



indra/llndof-linux/ndofdev.c


You are replacing the prebuilt installable AND adding the lib sources to 
the viewer source tree?

That can't be the right way, sorry.


- Boroondas


On June 3, 2011, 6:10 p.m., Altair Memo wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/322/
> ---
> 
> (Updated June 3, 2011, 6:10 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> fix for OPEN-21
> added EVDEV layer for linux users on 2.6.35+ kernels
> 
> - added both personal 3P libs and indra subdir (and cmake NDOF.cmake file 
> fix), first one less usefull, should be more better find a place where put 
> prebuilt lib (jira affect only linux)
> 
> 
> This addresses bug OPEN-21.
> http://jira.secondlife.com/browse/OPEN-21
> 
> 
> Diffs
> -
> 
>   autobuild.xml d74fd886c8a6 
>   doc/contributions.txt d74fd886c8a6 
>   indra/cmake/NDOF.cmake d74fd886c8a6 
>   indra/llndof-linux/CMakeLists.txt PRE-CREATION 
>   indra/llndof-linux/Makefile PRE-CREATION 
>   indra/llndof-linux/ndofdev.c PRE-CREATION 
>   indra/llndof-linux/ndofdev_external.h PRE-CREATION 
> 
> Diff: http://codereview.secondlife.com/r/322/diff
> 
> 
> Testing
> ---
> 
> I suppose "on my linux system work" is a poor point, using prebuilt òlibs 
> since long, the cmake and subdir work using autobuild with "ReleaseOS"
> 
> 
> Thanks,
> 
> Altair
> 
>

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: Viewer cache size increase to 10GB.

[Oz Linden]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/318/#review718
---



indra/newview/llfloaterpreference.cpp


I would prefer to see this done the other way (even though it produces a 
larger diff); test for the positive condition and enclose the resulting action 
in the 'then' block.

I dislike early returns.  While they are sometimes justifiable in a large 
routine for unusual cases, I don't think this fits that bill.

Not a show stopper, just a note for the future


- Oz


On June 3, 2011, 12:56 p.m., Log Linden wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/318/
> ---
> 
> (Updated June 3, 2011, 12:56 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> This patch increases the maximum and default viewer cache size values. Due to 
> limitations in the size of the VFS, the 80/20 texture cache/VFS split is 
> maintained up to 5GB, then the remaining cache size is given to the texture 
> cache. This caps the VFS size at 1GB ( up from .2 GB ).  I made corresponding 
> changes to the XUI to allow the slider to increase to the new cache size 
> maximum.
> 
> Bugfixes:
> * The reset cache location button will no longer tell the user that the cache 
> will be cleared if the cache is already in the default location.  Only the 
> notification was suppressed, the cache was never cleared by this button 
> unless the location changed.
> * The reset cache location button will now correctly clear the old cache when 
> it is reset back to the default location. 
> * I fixed an order of operation programming error in an llerrs log message in 
> the lltexturecache.cpp. This was showing wildly incorrect texture cache size 
> during a purge.
> * Code convention cleanup in llappviewer.cpp in initCache() and 
> lltexturecache.cpp
> 
> 
> This addresses bugs er-767, er-883 and er-883.
> http://jira.secondlife.com/browse/er-767
> http://jira.secondlife.com/browse/er-883
> http://jira.secondlife.com/browse/er-883
> 
> 
> Diffs
> -
> 
>   indra/newview/llappviewer.cpp 9c0506d10226 
>   indra/newview/llfloaterpreference.cpp 9c0506d10226 
>   indra/newview/lltexturecache.cpp 9c0506d10226 
>   indra/newview/skins/default/xui/en/panel_preferences_setup.xml 9c0506d10226 
> 
> Diff: http://codereview.secondlife.com/r/318/diff
> 
> 
> Testing
> ---
> 
> I have built and tested on all three platforms.  The log files indicate that 
> the caches are being initialised with the correct sizes.
> 
> 
> Thanks,
> 
> Log
> 
>

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: Viewer cache size increase to 10GB.

[Oz Linden]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/318/#review719
---

Ship it!


- Oz


On June 3, 2011, 12:56 p.m., Log Linden wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/318/
> ---
> 
> (Updated June 3, 2011, 12:56 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> This patch increases the maximum and default viewer cache size values. Due to 
> limitations in the size of the VFS, the 80/20 texture cache/VFS split is 
> maintained up to 5GB, then the remaining cache size is given to the texture 
> cache. This caps the VFS size at 1GB ( up from .2 GB ).  I made corresponding 
> changes to the XUI to allow the slider to increase to the new cache size 
> maximum.
> 
> Bugfixes:
> * The reset cache location button will no longer tell the user that the cache 
> will be cleared if the cache is already in the default location.  Only the 
> notification was suppressed, the cache was never cleared by this button 
> unless the location changed.
> * The reset cache location button will now correctly clear the old cache when 
> it is reset back to the default location. 
> * I fixed an order of operation programming error in an llerrs log message in 
> the lltexturecache.cpp. This was showing wildly incorrect texture cache size 
> during a purge.
> * Code convention cleanup in llappviewer.cpp in initCache() and 
> lltexturecache.cpp
> 
> 
> This addresses bugs er-767, er-883 and er-883.
> http://jira.secondlife.com/browse/er-767
> http://jira.secondlife.com/browse/er-883
> http://jira.secondlife.com/browse/er-883
> 
> 
> Diffs
> -
> 
>   indra/newview/llappviewer.cpp 9c0506d10226 
>   indra/newview/llfloaterpreference.cpp 9c0506d10226 
>   indra/newview/lltexturecache.cpp 9c0506d10226 
>   indra/newview/skins/default/xui/en/panel_preferences_setup.xml 9c0506d10226 
> 
> Diff: http://codereview.secondlife.com/r/318/diff
> 
> 
> Testing
> ---
> 
> I have built and tested on all three platforms.  The log files indicate that 
> the caches are being initialised with the correct sizes.
> 
> 
> Thanks,
> 
> Log
> 
>

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges