Re: Expose touchpad sensitivity in wsconsctl
People who prefer flatter profiles are not as rare as one might think,
cf similar discussions on Libinput:
https://bugs.freedesktop.org/show_bug.cgi?id=89485
I found setting it to 4 gives best results (it was 16 by default) so I
wouldn't want to totally remove it either.
Feel free to not merge this patch if you don't want it; I will not be
offended. As long as I have things working how I like on my own system :)
On 10/14/20 5:16 PM, Ulf Brosziewski wrote:
I'm not convinced that this makes sense. While there are still a lot of
touchpads around that need deceleration, modern ones tend to be larger and
more precise, so maybe we want to drop it at some point in the future?
Given that up to now, nobody else reported a problem with it, I'd prefer
to leave it in the set of "inofficial" configuration options.
On 10/14/20 9:13 PM, Brennan Vincent wrote:
Oops, the subject should be "Expose touchpad _decleration threshold_ in wsconsctl". Not
sure why I wrote "sensitivity".
On Wed, 14 Oct 2020, Brennan Vincent wrote:
diff --git sbin/wsconsctl/mouse.c sbin/wsconsctl/mouse.c
index e04642dacbc..0f1594e17e0 100644
--- sbin/wsconsctl/mouse.c
+++ sbin/wsconsctl/mouse.c
@@ -61,6 +61,7 @@ struct field mouse_field_tab[] = {
{ "tp.swapsides", _swapsides, FMT_CFG,
FLG_NORDBACK },
{ "tp.disable", _disable, FMT_CFG,FLG_NORDBACK
},
{ "tp.edges", _edges, FMT_CFG,FLG_NORDBACK },
+{ "tp.deceleration", _decel, FMT_CFG,FLG_NORDBACK },
{ "tp.param", _param, FMT_CFG,FLG_WRONLY },
/* Add an alias. This field is valid for all wsmouse devices. */
{ "param", _param, FMT_CFG,FLG_WRONLY },
diff --git sbin/wsconsctl/mousecfg.c sbin/wsconsctl/mousecfg.c
index 6d52bcbfc9c..6162df5c229 100644
--- sbin/wsconsctl/mousecfg.c
+++ sbin/wsconsctl/mousecfg.c
@@ -109,6 +109,12 @@ struct wsmouse_parameters cfg_revscroll = {
1
};
+struct wsmouse_parameters cfg_decel = {
+ (struct wsmouse_param[]) {
+ { WSMOUSECFG_DECELERATION, 0 }, },
+ 1
+};
+
struct wsmouse_parameters cfg_param = {
(struct wsmouse_param[]) {
{ -1, 0 },
diff --git sbin/wsconsctl/mousecfg.h sbin/wsconsctl/mousecfg.h
index 8e99139d280..97ef153fcb3 100644
--- sbin/wsconsctl/mousecfg.h
+++ sbin/wsconsctl/mousecfg.h
@@ -22,6 +22,7 @@ extern struct wsmouse_parameters cfg_edges;
extern struct wsmouse_parameters cfg_swapsides;
extern struct wsmouse_parameters cfg_disable;
extern struct wsmouse_parameters cfg_revscroll;
+extern struct wsmouse_parameters cfg_decel;
extern struct wsmouse_parameters cfg_param;
extern int cfg_touchpad;
Re: Expose touchpad sensitivity in wsconsctl
Oops, the subject should be "Expose touchpad _decleration threshold_ in
wsconsctl". Not sure why I wrote "sensitivity".
On Wed, 14 Oct 2020, Brennan Vincent wrote:
>
> diff --git sbin/wsconsctl/mouse.c sbin/wsconsctl/mouse.c
> index e04642dacbc..0f1594e17e0 100644
> --- sbin/wsconsctl/mouse.c
> +++ sbin/wsconsctl/mouse.c
> @@ -61,6 +61,7 @@ struct field mouse_field_tab[] = {
> { "tp.swapsides",_swapsides, FMT_CFG,
> FLG_NORDBACK },
> { "tp.disable", _disable, FMT_CFG,FLG_NORDBACK },
> { "tp.edges",_edges, FMT_CFG,FLG_NORDBACK },
> +{ "tp.deceleration", _decel, FMT_CFG,FLG_NORDBACK },
> { "tp.param",_param, FMT_CFG,FLG_WRONLY },
> /* Add an alias. This field is valid for all wsmouse devices. */
> { "param", _param, FMT_CFG,
> FLG_WRONLY },
> diff --git sbin/wsconsctl/mousecfg.c sbin/wsconsctl/mousecfg.c
> index 6d52bcbfc9c..6162df5c229 100644
> --- sbin/wsconsctl/mousecfg.c
> +++ sbin/wsconsctl/mousecfg.c
> @@ -109,6 +109,12 @@ struct wsmouse_parameters cfg_revscroll = {
> 1
> };
>
> +struct wsmouse_parameters cfg_decel = {
> + (struct wsmouse_param[]) {
> + { WSMOUSECFG_DECELERATION, 0 }, },
> + 1
> +};
> +
> struct wsmouse_parameters cfg_param = {
> (struct wsmouse_param[]) {
> { -1, 0 },
> diff --git sbin/wsconsctl/mousecfg.h sbin/wsconsctl/mousecfg.h
> index 8e99139d280..97ef153fcb3 100644
> --- sbin/wsconsctl/mousecfg.h
> +++ sbin/wsconsctl/mousecfg.h
> @@ -22,6 +22,7 @@ extern struct wsmouse_parameters cfg_edges;
> extern struct wsmouse_parameters cfg_swapsides;
> extern struct wsmouse_parameters cfg_disable;
> extern struct wsmouse_parameters cfg_revscroll;
> +extern struct wsmouse_parameters cfg_decel;
> extern struct wsmouse_parameters cfg_param;
> extern int cfg_touchpad;
>
>
Expose touchpad sensitivity in wsconsctl
diff --git sbin/wsconsctl/mouse.c sbin/wsconsctl/mouse.c
index e04642dacbc..0f1594e17e0 100644
--- sbin/wsconsctl/mouse.c
+++ sbin/wsconsctl/mouse.c
@@ -61,6 +61,7 @@ struct field mouse_field_tab[] = {
{ "tp.swapsides", _swapsides, FMT_CFG,FLG_NORDBACK },
{ "tp.disable",_disable, FMT_CFG,FLG_NORDBACK },
{ "tp.edges", _edges, FMT_CFG,FLG_NORDBACK },
+{ "tp.deceleration", _decel, FMT_CFG,FLG_NORDBACK },
{ "tp.param", _param, FMT_CFG,FLG_WRONLY },
/* Add an alias. This field is valid for all wsmouse devices. */
{ "param", _param, FMT_CFG,FLG_WRONLY },
diff --git sbin/wsconsctl/mousecfg.c sbin/wsconsctl/mousecfg.c
index 6d52bcbfc9c..6162df5c229 100644
--- sbin/wsconsctl/mousecfg.c
+++ sbin/wsconsctl/mousecfg.c
@@ -109,6 +109,12 @@ struct wsmouse_parameters cfg_revscroll = {
1
};
+struct wsmouse_parameters cfg_decel = {
+ (struct wsmouse_param[]) {
+ { WSMOUSECFG_DECELERATION, 0 }, },
+ 1
+};
+
struct wsmouse_parameters cfg_param = {
(struct wsmouse_param[]) {
{ -1, 0 },
diff --git sbin/wsconsctl/mousecfg.h sbin/wsconsctl/mousecfg.h
index 8e99139d280..97ef153fcb3 100644
--- sbin/wsconsctl/mousecfg.h
+++ sbin/wsconsctl/mousecfg.h
@@ -22,6 +22,7 @@ extern struct wsmouse_parameters cfg_edges;
extern struct wsmouse_parameters cfg_swapsides;
extern struct wsmouse_parameters cfg_disable;
extern struct wsmouse_parameters cfg_revscroll;
+extern struct wsmouse_parameters cfg_decel;
extern struct wsmouse_parameters cfg_param;
extern int cfg_touchpad;
Re: Any reason there's no way to persist pledge(2) state across exec?
Got it. Thanks for the explanation. On Sun, Apr 10, 2016, at 01:36 PM, Stuart Henderson wrote: > On 2016/04/10 20:50, Nicholas Marriott wrote: > > Hi > > > > What's the use for this? What program could use it? > > > > On Sun, Apr 10, 2016 at 08:48:08AM -0700, Brennan Vincent wrote: > > > Subject basically says it all. I think some could find it useful to have > > > `pledge` promises optionally persist even after the process calls > > > execve. This could, for example, be implemented with an `exec_noreset` > > > pledge that gives access to the same syscalls as `exec`, but with this > > > restricted behavior. > > > > > > Is there a good technically reason this can't or shouldn't be done, or > > > has it simply not been implemented yet? > > It doesn't seem like something that would be widely usable - a big > part of how pledge is designed is based around the fact that programs > typically need a higher level of access during startup (to open files, > persistent sockets, etc) and can then be ratcheted down to a very small > set of system calls after init is done. > > I don't think there's a technical reason why it couldn't be done, > but it would add complexity in a security-sensitive area so it's > unlikely to happen without a number of real-world use cases. >
Re: Any reason there's no way to persist pledge(2) state across exec?
I imagine it could be used to provide rudimentary sandboxing (running untrusted or partially-trusted code and limiting what it is allowed to access). Let me know if I am mistaken. On Sun, Apr 10, 2016, at 12:50 PM, Nicholas Marriott wrote: > Hi > > What's the use for this? What program could use it? > > > On Sun, Apr 10, 2016 at 08:48:08AM -0700, Brennan Vincent wrote: > > Subject basically says it all. I think some could find it useful to have > > `pledge` promises optionally persist even after the process calls > > execve. This could, for example, be implemented with an `exec_noreset` > > pledge that gives access to the same syscalls as `exec`, but with this > > restricted behavior. > > > > Is there a good technically reason this can't or shouldn't be done, or > > has it simply not been implemented yet? > >
Any reason there's no way to persist pledge(2) state across exec?
Subject basically says it all. I think some could find it useful to have `pledge` promises optionally persist even after the process calls execve. This could, for example, be implemented with an `exec_noreset` pledge that gives access to the same syscalls as `exec`, but with this restricted behavior. Is there a good technically reason this can't or shouldn't be done, or has it simply not been implemented yet?
