[Bf-committers] Re: [Bf-blender-cvs] CVS commit: blender/source/blender/src interface.c

[Ton Roosendaal]

Hi Matt,

The bug comes from the fact that you check for get_tablet_data() to  
validate if there's a tablet. That doesn't work. It always returns a  
pointer. It is a pointer to a member of an internal struct in Ghost, of  
which I cannot see yet where it is initialized or allocated. By default  
(for me) the pressure value is zero, disabling sliding in buttons.

The tablet implementation really needs more work.

- There is no description of this tablet API. (code added without  
comments)
- The API is confusing, it goes 5 wrappers deep only to find a pointer  
inside of the ghost window. Of which it is undefined if that's  
initialized
- You export an internal Ghost struct and include file to blender  
(GHOST_Types.h). Don't!

It would have worked better if;

- there was a call to check for a tablet connected/initalized
- there was a clear memory initialize in ghost for this stuff
- the ghostwinlay.c would get tablet info from ghost, and store locally  
in own window structs, not exporting ghost functions to rest Blender.

I've disabled the call to support sliding in number buttons. But, the  
issues with tablets for other features are probably related...


-Ton-


On 25 Mar, 2007, at 12:50, Matt Ebb wrote:

>
> On 25/03/2007, at 8:26 PM, Stephen Swaney wrote:
>
>> On Sun, Mar 25, 2007 at 05:42:27PM +1000, Matt Ebb wrote:
>>>
>>> As mentioned in the commit log, I know that some people have had
>>> problems related to this sort of thing in the past, which is why
>>> although it should be fine and is fine for most people, I added the
>>> rt workaround for now. In order to figure out what the root of this
>>> uncommon problem is, I need a clear report about what's going on,
>>> with detailed system information about OS versions, tablet drivers,
>>> etc, so I would encourage Stephen or anyone else with this issue to
>>> please post a report. It would also be very useful debugging
>>> information to know whether the 'td' pointer is null or not on those
>>> systems in that section of code, and what the td->pressure value is.
>>
>> I am not sure I would describe this as an 'uncommon problem'. Others
>> on IRC have complained about it not working.
>>
>> I'm not using a tablet, just the mouse. In some windows, numbuts were
>> not working at all. In others the slider behavior was very erratic.
>> Depending on the particular button, values were changing extremely
>> slowly or in one direction only.
>>
>> Since the feature seemed completely b0rked, I rolled it back on my box
>> with
>> cvs update -j 1.260 -j 1.259 source/blender/src/interface.c
> Well, if it is indeed a widespread problem, I'm happy to disable it  
> for now (when makefiles build again) while a solution can be found.  
> However there was only one report about something similar happening in  
> sculpt mode, using the same tablet data, and there wasn't sufficient  
> information posted to help find exactly what the problem could be -  
> that seemed quite isolated. Can you use sculpt mode and image painting  
> too?
>
> But I really would like information to help find the cause of this  
> since it's related to the underlying tablet support, not what I  
> committed the other day. If anyone experiencing this could post a  
> detailed bug report as mentioned previously, it would be a great help.
>
> cheers,
>
> Matt
>
>
> ------------------------------------------
> Matt Ebb . matt at mke3.net . http://mke3.net
>
>
>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
>
------------------------------------------------------------------------ 
--
Ton Roosendaal  Blender Foundation ton at blender.org  
http://www.blender.org