Re: [Linuxwacom-devel] Sample xsetwacom scripts vetting
On Tue, Mar 01, 2011 at 12:19:42PM -0600, Favux ... wrote: Xorg.conf.d is finished. Please review it when you get a chance. Done, I think. Please let me know if I culled too much. IMO, one example is enough and we should rely on our users being smart enough to interpolate from the examples. Cheers, Peter On Sun, Feb 27, 2011 at 8:59 PM, Peter Hutterer peter.hutte...@who-t.net wrote: thanks. As you can see from the history, I'd like to make this new page the main [[xorg.conf.d]] page and link to it from Configuring_X. there's plenty of information we should provide that it warrants a separate page. especially since we have different configurations for 1.8, 1.9 and 1.10. I haven't really finished with it yet though, I'll try to edit it over the next few days. The main plan is: - use MatchDriver instead of duplicating the matches (for server 1.9+) - don't tell users to search for the right snippets (they stack anyway), just explain how they can write one that applies to their device Cheers, Peter -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] Sample xsetwacom scripts vetting
Alright, looks good. I think I like the new tip appearance. Intriguing anyway. If we do a separate Bamboo page do we pull the examples along and put new examples in the Xorg.conf.d? Favux On Tue, Mar 1, 2011 at 5:36 PM, Peter Hutterer peter.hutte...@who-t.net wrote: On Tue, Mar 01, 2011 at 12:19:42PM -0600, Favux ... wrote: Xorg.conf.d is finished. Please review it when you get a chance. Done, I think. Please let me know if I culled too much. IMO, one example is enough and we should rely on our users being smart enough to interpolate from the examples. Cheers, Peter On Sun, Feb 27, 2011 at 8:59 PM, Peter Hutterer peter.hutte...@who-t.net wrote: thanks. As you can see from the history, I'd like to make this new page the main [[xorg.conf.d]] page and link to it from Configuring_X. there's plenty of information we should provide that it warrants a separate page. especially since we have different configurations for 1.8, 1.9 and 1.10. I haven't really finished with it yet though, I'll try to edit it over the next few days. The main plan is: - use MatchDriver instead of duplicating the matches (for server 1.9+) - don't tell users to search for the right snippets (they stack anyway), just explain how they can write one that applies to their device Cheers, Peter -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] Sample xsetwacom scripts vetting
On Tue, Mar 1, 2011 at 7:42 PM, Peter Hutterer peter.hutte...@who-t.net wrote: On Tue, Mar 01, 2011 at 07:35:02PM -0600, Favux ... wrote: Alright, looks good. I think I like the new tip appearance. Intriguing anyway. If we do a separate Bamboo page do we pull the examples along and put new examples in the Xorg.conf.d? yeah I think so. the example in the xorg.conf.d page should be the standard example without special cases. btw, Chris: wasn't there a Bamboo change in the kernel that the devices are now on a single device? Or am I confusing something here? Its still two devices in all versions. We talked about merging them but tabled it for now. I'm sure It will come up again at some point in Xinput 2.1 and pointer emulation discussions. Chris -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] Sample xsetwacom scripts vetting
On Tue, Mar 1, 2011 at 5:42 PM, Peter Hutterer peter.hutte...@who-t.netwrote: On Tue, Mar 01, 2011 at 07:35:02PM -0600, Favux ... wrote: Alright, looks good. I think I like the new tip appearance. Intriguing anyway. If we do a separate Bamboo page do we pull the examples along and put new examples in the Xorg.conf.d? yeah I think so. the example in the xorg.conf.d page should be the standard example without special cases. btw, Chris: wasn't there a Bamboo change in the kernel that the devices are now on a single device? Or am I confusing something here? No, pen and touch are not on the same logical port (if that is what you are asking for). This is true for all pen and touch enabled devices, not just Bamboo or Wacom devices. If we want to unify them, we would have to redesign it in the HID-layer for all pen and touch enabled devices. It can not be done within Wacom kernel driver. Ping -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] Sample xsetwacom scripts vetting
I'm liking the look of the Table of Contents above a header less overview. Do you want to make it part of the linuxwacom project mediawiki style? Favux On Sun, Feb 27, 2011 at 8:59 PM, Peter Hutterer peter.hutte...@who-t.net wrote: thanks. As you can see from the history, I'd like to make this new page the main [[xorg.conf.d]] page and link to it from Configuring_X. there's plenty of information we should provide that it warrants a separate page. especially since we have different configurations for 1.8, 1.9 and 1.10. I haven't really finished with it yet though, I'll try to edit it over the next few days. The main plan is: - use MatchDriver instead of duplicating the matches (for server 1.9+) - don't tell users to search for the right snippets (they stack anyway), just explain how they can write one that applies to their device Cheers, Peter -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] Sample xsetwacom scripts vetting
On Sun, Feb 27, 2011 at 02:13:14PM -0600, Favux ... wrote: Hi Peter, FYI the Tablet Configuration HOWTO is essentially complete. You can remove the Tablet PC Configuration and Wacom Tablet Configuration pages whenever you are ready to. The 52-wacom-options.conf is a template. I won't add it to Configuring X until you've had a chance to review it. thanks. As you can see from the history, I'd like to make this new page the main [[xorg.conf.d]] page and link to it from Configuring_X. there's plenty of information we should provide that it warrants a separate page. especially since we have different configurations for 1.8, 1.9 and 1.10. I haven't really finished with it yet though, I'll try to edit it over the next few days. The main plan is: - use MatchDriver instead of duplicating the matches (for server 1.9+) - don't tell users to search for the right snippets (they stack anyway), just explain how they can write one that applies to their device Cheers, Peter -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] Sample xsetwacom scripts vetting
On Tue, Feb 22, 2011 at 11:36 PM, Peter Hutterer peter.hutte...@who-t.net wrote: This is a sample of the the sample scripts. The idea is to provide a text file as a framework to alter the tablet settings, similar to what wacomcpl would have produced in its xsetwacom script file .xinitrc. I don't have to mention that wacomcpl is broken by design since server 1.4? and these scripts replicate the issue. No, no need. However since you object to ad hoc solutions such as a daemon to monitor events, runtime xsetwacom commands will remain broken until integrated into the Desktops. And presumably at that point become obsolete. Except it is broken into input tool sections. This makes it easier for the user to see what parameter adjustments are useful for a given input tool. why don't we add this information to the man page? if only half the time that is spent on writing scripts to hack things up would be spent on proper documentation in the driver we wouldn't need the scripts in the first place... It's always good to improve the documentation. I'm not sure how that follows though. The information is from the man pages. The scripts serve as a concrete example of the man page information in use. Or are you suggesting running each runtime command separately in a terminal rather than as a script? How is that helpful to a user? The pad section attempts to mimic the physical button layout for the tablet. I use the generic name .xsetwacom.sh for them. The defaults are used and stated with the ranges in the comments for ease of use. This is obviously a hack while we wait for tablet gui's for Gnome and KDE and the rest. As an aside I noticed the plan for the Gnome gui is to be for tablets only, not tablet PCs. Hopefully they will be able to use it anyway. if you refer to the missing touch, that's just the current implementation. I'm still waiting for a UI designer to review my suggestion. The relevant links are in the mediawiki's External applications in the 'Graphical Configuration Tools' section, along with: http://bugzilla-attachments.gnome.org/attachment.cgi?id=179668 http://live.gnome.org/Design/SystemSettings/Tablet http://live.gnome.org/Design/System%20Settings/Tablet/Screen other than that, there is no plan aside from peter hacks it up whenever he finds a spare minute somewhere. I've gotten zero feedback for this tool so far so I'm still operating blindly. I realize that. Hopefully some of the content, including the scripts, help a little. As I mentioned earlier it would be nice to have some graphics professionals chime in along with some UI designers. We did have an IT supervisor from a professional graphics shop speak up a few weeks ago about the lack of a daemon or whatever to reapply .xinitrc settings lost due to a hot plug. This was proving problematic for his large deployment of Intuos4's on KVM switches to his RHEL6 based servers/workstations. Since he was from an internationally respected, household name graphics art shop we perhaps missed an opportunity for a fruitful dialog. He did provide feedback in the form of posting their solution, a modification of cyberfish's daemon to monitor hot plugging. The other solid feedback we had was from Alexia (a Gimp dev.) and her patch set using tool serial numbers to distinguish between input tools so they can have different settings. That would be valuable for any gui. Hopefully that hasn't fizzled out and Alexia will be back with an update after the last round of reviews. Right now the pre-0.10-11 parameter names are used as the majority of users are probably still pre-0.10-11 and will be until Natty, Fedora 15, etc. are released in a few months. The user can go on to use a subset of the script, usually the pad button assignments with maybe stylus pressure etc., to generate a profile for various programs such as Gimp if they desire. Which is one of the reasons for showing alternate button assignment examples for specific graphics programs. The general tablet script is placed in a start up file and the profiles in launchers. We've been using them on Ubuntu forums since Lucid (10.04) X server 1.7 released April 2010. That was from an experiment, because a lot of users wanted to use ID #'s. They felt the device names were too long and cumbersome. I was demonstrating both worked. However since ID #'s can change with hot plugging I generally encourage using the device names. Although the comments explain this I could change the scripts to just device name? ok, my main issue with the scripts is that they duplicate the device names heavily, which makes them hard to update (yes, search/replace, I know) and hard to read. worse, TabletPC-1FGT.sh mixes IDs and device names. one approach would be: DEV=Wacom Cintiq 12UX2 STYLUS=$DEV stylus PAD=$DEV pad xsetwacom set $STYLUS Suppress 4 xsetwacom set $STYLUS RawSample 2 ... No objection to this in principle. I thought it
Re: [Linuxwacom-devel] Sample xsetwacom scripts vetting
On Wed, Feb 23, 2011 at 2:55 PM, Favux ... favux...@gmail.com wrote:
On Wed, Feb 23, 2011 at 10:03 AM, Chris Bagwell ch...@cnpbagwell.com wrote:
On Tue, Feb 22, 2011 at 11:36 PM, Peter Hutterer
peter.hutte...@who-t.net wrote:
why don't we add this information to the man page?
if only half the time that is spent on writing scripts to hack things up
would be spent on proper documentation in the driver we wouldn't need the
scripts in the first place...
Agree with this point. And I've come to enjoy improvements to xinput
list-props were it only shows values that make sense for current tool
(or xsetwacom equivalent).
So we want the user to read man wacom, xsetwacom, xinput and then
assemble their own script combining xsetwacom and xinput? I agree
that the xinput improvements are welcomed and proving useful and I've
added xinput commands to my scripts.
I've looked at the screenshot but not code yet. :-) I'm waiting on
that UI designer as well. I'm always leery of hacking on something
when I know someone is going to come back and say it needs just one
button on the screen that says 'make it work' and get rid of the
rest... and make most the time useless.
Getting UI input is proving problematic.
Are these bash scripts?
They are an imititation of wacomcpl's .xinitrc, except organized into
input tool sections and minus at the end of the script:
# run the primary system script
. /etc/X11/xinit/xinitrc
Which is the old X script chain.
For the cosmetic name changes, you can use
associative arrays to hide some of this.
declare -A name_remap
if [ $xsetwacom_version -qt 2 ]; then
$name_remap[ClickForce]=Threshold
else
$name_remap[ClickForce]=ClickForce
fi
xsetwacom $STYLUS $name_remap[ClickForce] 27
Of course, how to set xsetwacom_version is a little tricky. My idea
above is to remap the 0.10.x type version #'s to an easier to parse
integer. For versions of xsetwacom that have same interface, they map
to same integer value.
Partial example:
case `xsetwacom -V | awk 'NR==1{print $1}' in
0.10.1|0.10.2) xsetwacom_version=1;;
0.10.11|*) xsetwacom_version=2;;
esac
Fair enough, and good ideas. But rather than blowing the users mind
on exposure to this wouldn't an interface hiding this be better?
While some Wacom users have put in the time to learn the xsetwacom
interface that doesn't mean they've learned BASH scripting, or want
to.
OK. I guess I'm missing parts of this topic. Sometimes it sounds
like these are examples only but other times it sounds like its meant
to be ran by some daemon backend or similar during hotplugs.
If they are ever meant to be plugged into a backend then I'd assume
most the hard stuff like xsetwacom_version or $STYLUS are
automatically set for user. But then again, I'd go the easier route
for user and just have them set things like:
TOUCH_THRESHOLD=27
STYLUS_PRESSURECURVE=0 0 100 100
STYLUS_THRESHOLD=27
Then user doesn't even now they are really a bash script and looks
dangerously close to windows *.INI they may already be familiar with
for same types of stuff.
At plugin time, source the above file, and start updating everything
optionally and one by one:
if xinput list | grep $HOTPLUG_NAME | grep touch; then
TOUCH=$HOTPLUG_NAME touch
fi
if [ ${TOUCH}x != x ]; then
if [ ${TOUCH_THRESHOLD != x ]; then
xsetwacom $TOUCH $threshold_name[$xsetwacom_version] $TOUCH_TRESHOLD
fi
fi
Then you are at long term easier to maintain all-in-one script as
Peter suggestions.
But I think I must be missing overall intent here.
Chris
--
Free Software Download: Index, Search Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] Sample xsetwacom scripts vetting
Hi Chris,
Actually you're up to speed I think. They're meant to be a stop gap
for the user while we're waiting for a gui. They're examples that can
be used currently with the intention of the user modifying the
parameter values to what they want/require.
Since they essentially duplicate wacomcpl's backend .xinitrc,
solutions like daemons that worked for it will work for the
.xsetwacom.sh scripts too.
You're just going further along the road Peter started and actually
coming up with a replacement for wacomcpl. Just needs a simple gui
slapped on it.
Favux
On Wed, Feb 23, 2011 at 3:35 PM, Chris Bagwell ch...@cnpbagwell.com wrote:
OK. I guess I'm missing parts of this topic. Sometimes it sounds
like these are examples only but other times it sounds like its meant
to be ran by some daemon backend or similar during hotplugs.
If they are ever meant to be plugged into a backend then I'd assume
most the hard stuff like xsetwacom_version or $STYLUS are
automatically set for user. But then again, I'd go the easier route
for user and just have them set things like:
TOUCH_THRESHOLD=27
STYLUS_PRESSURECURVE=0 0 100 100
STYLUS_THRESHOLD=27
Then user doesn't even now they are really a bash script and looks
dangerously close to windows *.INI they may already be familiar with
for same types of stuff.
At plugin time, source the above file, and start updating everything
optionally and one by one:
if xinput list | grep $HOTPLUG_NAME | grep touch; then
TOUCH=$HOTPLUG_NAME touch
fi
if [ ${TOUCH}x != x ]; then
if [ ${TOUCH_THRESHOLD != x ]; then
xsetwacom $TOUCH $threshold_name[$xsetwacom_version] $TOUCH_TRESHOLD
fi
fi
Then you are at long term easier to maintain all-in-one script as
Peter suggestions.
But I think I must be missing overall intent here.
Chris
--
Free Software Download: Index, Search Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev
___
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] Sample xsetwacom scripts vetting - off-topic
I removed the contents of this thread on purpose since I am not going to comment on any specific topics. So far, both sides have showed the passion about this project, which is great for the project. Both sides have also showed their strength in dealing with technical issues, which is essential to the success of this project. The discussion itself is very healthy, which inspired me to think about the topics outside of this thread. With a developer mindset, whenever facing an issue or a challenge, I try to figure out the root cause or the bottleneck. When I read through the replies, I feel the root cause is the lack of a configuration UI for tablet devices. Peter has put countless effort in providing a generic UI in the desktop environment, which is the right way to go (I mean the common UI, not the extra effort ;). But, we don't seem to get the UI into gnome anytime soon since it is out of this project's control. Then, do we have options between now and the time when the UI is available in the desktop environment? This boils down to one question: what is the goal of this project? Is it a development only project or do we also care about end users? If this project only needs to develop driver for tablet-related devices, we don't have to care about the UI at all. The script is out of the question. If we want to provide help to end users, those scripts can be considered as solutions for end users before the UI is available. Since they are technically not code, the vetting rules should be different. Judging the scripts from their usefulness as end users makes more sense than from the technical correctness as developers, let alone not everyone has the same technical background to reach the same level of completeness. After all, I guess, the scripts will not be included in the release package. They will only be posted at mediawiki, where they can be updated as often as we wish. I know I am a stubborn person. Trying to change my mindset has been a big challenge for me, where the root cause is beyond my control and unfixable ;). But, I do have a simple workaround for it - accept other's mindset just as we would like them to accept ours. Ping -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] Sample xsetwacom scripts vetting
On Wed, Feb 23, 2011 at 01:46:40PM -0600, Favux ... wrote: On Tue, Feb 22, 2011 at 11:36 PM, Peter Hutterer peter.hutte...@who-t.net wrote: This is a sample of the the sample scripts. The idea is to provide a text file as a framework to alter the tablet settings, similar to what wacomcpl would have produced in its xsetwacom script file .xinitrc. I don't have to mention that wacomcpl is broken by design since server 1.4? and these scripts replicate the issue. No, no need. However since you object to ad hoc solutions such as a daemon to monitor events, runtime xsetwacom commands will remain broken until integrated into the Desktops. And presumably at that point become obsolete. sorry, I may need to clarify this. There's a fine line between a solution that works for now and something that's officially endorsed by the upstream project (us, in this case) and may cause issues in the long run. I have no problems with someone writing said daemon but I don't think it should be part of linuxwacom. precisely because it is a stopgap solution. fwiw, a similar daemon was proposed in https://bugzilla.gnome.org/show_bug.cgi?id=635486 and it would lead to such xsetwacom scripts to work. so I'm not against the the scripts themselves (given some cleanup), but we must be very careful about what we endorse as an official solution. Except it is broken into input tool sections. This makes it easier for the user to see what parameter adjustments are useful for a given input tool. why don't we add this information to the man page? if only half the time that is spent on writing scripts to hack things up would be spent on proper documentation in the driver we wouldn't need the scripts in the first place... It's always good to improve the documentation. I'm not sure how that follows though. The information is from the man pages. The scripts serve as a concrete example of the man page information in use. Or are you suggesting running each runtime command separately in a terminal rather than as a script? How is that helpful to a user? man xsetwacom so far only lists 5 parameters. we need to improve this. The pad section attempts to mimic the physical button layout for the tablet. I use the generic name .xsetwacom.sh for them. The defaults are used and stated with the ranges in the comments for ease of use. This is obviously a hack while we wait for tablet gui's for Gnome and KDE and the rest. As an aside I noticed the plan for the Gnome gui is to be for tablets only, not tablet PCs. Hopefully they will be able to use it anyway. if you refer to the missing touch, that's just the current implementation. I'm still waiting for a UI designer to review my suggestion. The relevant links are in the mediawiki's External applications in the 'Graphical Configuration Tools' section, along with: http://bugzilla-attachments.gnome.org/attachment.cgi?id=179668 http://live.gnome.org/Design/SystemSettings/Tablet http://live.gnome.org/Design/System%20Settings/Tablet/Screen other than that, there is no plan aside from peter hacks it up whenever he finds a spare minute somewhere. I've gotten zero feedback for this tool so far so I'm still operating blindly. I realize that. Hopefully some of the content, including the scripts, help a little. As I mentioned earlier it would be nice to have some graphics professionals chime in along with some UI designers. I've tried to talk to a few guys at LCA a few weeks back. It's depressing. Everyone seems to want a config interface but I never get any concrete answers to what tweaks do you actually need?. hence why the gnome tool mostly duplicates what wacomcpl did. We did have an IT supervisor from a professional graphics shop speak up a few weeks ago about the lack of a daemon or whatever to reapply .xinitrc settings lost due to a hot plug. This was proving problematic for his large deployment of Intuos4's on KVM switches to his RHEL6 based servers/workstations. Since he was from an internationally respected, household name graphics art shop we perhaps missed an opportunity for a fruitful dialog. He did provide feedback in the form of posting their solution, a modification of cyberfish's daemon to monitor hot plugging. The other solid feedback we had was from Alexia (a Gimp dev.) and her patch set using tool serial numbers to distinguish between input tools so they can have different settings. That would be valuable for any gui. Hopefully that hasn't fizzled out and Alexia will be back with an update after the last round of reviews. Right now the pre-0.10-11 parameter names are used as the majority of users are probably still pre-0.10-11 and will be until Natty, Fedora 15, etc. are released in a few months. The user can go on to use a subset of the script, usually the pad button assignments with maybe stylus pressure etc., to generate a profile for various programs such
[Linuxwacom-devel] Sample xsetwacom scripts vetting
Hi, Peter would like these scripts vetted. So if you get a chance please review them and comment. This is a sample of the the sample scripts. The idea is to provide a text file as a framework to alter the tablet settings, similar to what wacomcpl would have produced in its xsetwacom script file .xinitrc. Except it is broken into input tool sections. This makes it easier for the user to see what parameter adjustments are useful for a given input tool. The pad section attempts to mimic the physical button layout for the tablet. I use the generic name .xsetwacom.sh for them. The defaults are used and stated with the ranges in the comments for ease of use. This is obviously a hack while we wait for tablet gui's for Gnome and KDE and the rest. As an aside I noticed the plan for the Gnome gui is to be for tablets only, not tablet PCs. Hopefully they will be able to use it anyway. Right now the pre-0.10-11 parameter names are used as the majority of users are probably still pre-0.10-11 and will be until Natty, Fedora 15, etc. are released in a few months. The user can go on to use a subset of the script, usually the pad button assignments with maybe stylus pressure etc., to generate a profile for various programs such as Gimp if they desire. Which is one of the reasons for showing alternate button assignment examples for specific graphics programs. The general tablet script is placed in a start up file and the profiles in launchers. We've been using them on Ubuntu forums since Lucid (10.04) X server 1.7 released April 2010. Thank you. Favux Cintiq.sh Description: Bourne shell script Intuos4.sh Description: Bourne shell script BambooPT.sh Description: Bourne shell script TabletPC-1FGT.sh Description: Bourne shell script TabletPC-2FGT.sh Description: Bourne shell script -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
Re: [Linuxwacom-devel] Sample xsetwacom scripts vetting
On Tue, Feb 22, 2011 at 02:35:19PM -0600, Favux ... wrote: Peter would like these scripts vetted. So if you get a chance please review them and comment. This is a sample of the the sample scripts. The idea is to provide a text file as a framework to alter the tablet settings, similar to what wacomcpl would have produced in its xsetwacom script file .xinitrc. I don't have to mention that wacomcpl is broken by design since server 1.4? and these scripts replicate the issue. Except it is broken into input tool sections. This makes it easier for the user to see what parameter adjustments are useful for a given input tool. why don't we add this information to the man page? if only half the time that is spent on writing scripts to hack things up would be spent on proper documentation in the driver we wouldn't need the scripts in the first place... The pad section attempts to mimic the physical button layout for the tablet. I use the generic name .xsetwacom.sh for them. The defaults are used and stated with the ranges in the comments for ease of use. This is obviously a hack while we wait for tablet gui's for Gnome and KDE and the rest. As an aside I noticed the plan for the Gnome gui is to be for tablets only, not tablet PCs. Hopefully they will be able to use it anyway. if you refer to the missing touch, that's just the current implementation. I'm still waiting for a UI designer to review my suggestion. other than that, there is no plan aside from peter hacks it up whenever he finds a spare minute somewhere. I've gotten zero feedback for this tool so far so I'm still operating blindly. Right now the pre-0.10-11 parameter names are used as the majority of users are probably still pre-0.10-11 and will be until Natty, Fedora 15, etc. are released in a few months. The user can go on to use a subset of the script, usually the pad button assignments with maybe stylus pressure etc., to generate a profile for various programs such as Gimp if they desire. Which is one of the reasons for showing alternate button assignment examples for specific graphics programs. The general tablet script is placed in a start up file and the profiles in launchers. We've been using them on Ubuntu forums since Lucid (10.04) X server 1.7 released April 2010. ok, my main issue with the scripts is that they duplicate the device names heavily, which makes them hard to update (yes, search/replace, I know) and hard to read. worse, TabletPC-1FGT.sh mixes IDs and device names. one approach would be: DEV=Wacom Cintiq 12UX2 STYLUS=$DEV stylus PAD=$DEV pad xsetwacom set $STYLUS Suppress 4 xsetwacom set $STYLUS RawSample 2 ... once you start looking at that, you notice that the scripts are mostly identical. At which point I'm starting to wonder why we have 5 different scripts? as with all scripts, forcing defaults to the default value is generally a bad idea. It means that if we change the defaults in the driver to improve the behaviour users won't notice because they're blindly applying some settings. It also means we won't get user feedback because they don't even know anything has changed. I'm not sure why there is a alternative pad button assignment examples section. Surely users who figure out Button2 key ctrl also figure out key shift without having someone pre-fill those in? and some of the settings are confusing at best. BambooPT's button assignments are rather random and that's afaict the only thing that's not set to the defaults. Cheers, Peter -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
