[DISCUSSION] Weston-Init and non-root weston

[DISCUSSION] Weston-Init and non-root weston

[Randolph Sapp]

Finally getting around to weston-init issue I highlighted a while back 
and there's only one real issue preventing us from reusing the base 
weston-init recipe -- our touchscreen auto-configuration script.

That script has to have root access to setup and reload udev rules and 
as we know setuid won't work for shell scripts.

I propose we rewrite it in something that can use setuid (perl or c or 
something of the sort). I'm currently looking at perl as there's already 
quite a few core recipes that rdepend on it.

Then we just need to inject it into the runWeston script and adjust the 
two init scripts to point at that.

Any concerns or objections?

Re: [DISCUSSION] Weston-Init and non-root weston

[Andrew Davis]

On 4/17/23 5:32 PM, Randolph Sapp wrote:
> Finally getting around to weston-init issue I highlighted a while back and there's only one real issue preventing us from reusing the base weston-init recipe -- our touchscreen auto-configuration script.
> 
> That script has to have root access to setup and reload udev rules and as we know setuid won't work for shell scripts.
> 
> I propose we rewrite it in something that can use setuid (perl or c or something of the sort). I'm currently looking at perl as there's already quite a few core recipes that rdepend on it.
> 
> Then we just need to inject it into the runWeston script and adjust the two init scripts to point at that.
> 
> Any concerns or objections?

Why not just drop out that old touchscreen script, it is a non-standard way of doing
this task and should be removed.

Andrew

Re: [DISCUSSION] Weston-Init and non-root weston

[Randolph Sapp]

On 4/17/23 17:39, Andrew Davis wrote:
> On 4/17/23 5:32 PM, Randolph Sapp wrote:
>> Finally getting around to weston-init issue I highlighted a while back 
>> and there's only one real issue preventing us from reusing the base 
>> weston-init recipe -- our touchscreen auto-configuration script.
>>
>> That script has to have root access to setup and reload udev rules and 
>> as we know setuid won't work for shell scripts.
>>
>> I propose we rewrite it in something that can use setuid (perl or c or 
>> something of the sort). I'm currently looking at perl as there's 
>> already quite a few core recipes that rdepend on it.
>>
>> Then we just need to inject it into the runWeston script and adjust 
>> the two init scripts to point at that.
>>
>> Any concerns or objections?
> 
> Why not just drop out that old touchscreen script, it is a non-standard 
> way of doing
> this task and should be removed.
> 
> Andrew

It's non-standard, but that's because there really isn't a good standard 
for calibrating touch screens under Weston. AFAIK this is still useful.

Re: [DISCUSSION] Weston-Init and non-root weston

[Andrew Davis]

On 4/17/23 5:43 PM, Randolph Sapp wrote:
> On 4/17/23 17:39, Andrew Davis wrote:
>> On 4/17/23 5:32 PM, Randolph Sapp wrote:
>>> Finally getting around to weston-init issue I highlighted a while back and there's only one real issue preventing us from reusing the base weston-init recipe -- our touchscreen auto-configuration script.
>>>
>>> That script has to have root access to setup and reload udev rules and as we know setuid won't work for shell scripts.
>>>
>>> I propose we rewrite it in something that can use setuid (perl or c or something of the sort). I'm currently looking at perl as there's already quite a few core recipes that rdepend on it.
>>>
>>> Then we just need to inject it into the runWeston script and adjust the two init scripts to point at that.
>>>
>>> Any concerns or objections?
>>
>> Why not just drop out that old touchscreen script, it is a non-standard way of doing
>> this task and should be removed.
>>
>> Andrew
> 
> It's non-standard, but that's because there really isn't a good standard for calibrating touch screens under Weston. AFAIK this is still useful.

https://wiki.st.com/stm32mpu/wiki/How_to_calibrate_the_touchscreen

This seems like the standard ^^

Andrew

Re: [DISCUSSION] Weston-Init and non-root weston

[Randolph Sapp]

On 4/17/23 17:52, Andrew Davis wrote:
> On 4/17/23 5:43 PM, Randolph Sapp wrote:
>> On 4/17/23 17:39, Andrew Davis wrote:
>>> On 4/17/23 5:32 PM, Randolph Sapp wrote:
>>>> Finally getting around to weston-init issue I highlighted a while 
>>>> back and there's only one real issue preventing us from reusing the 
>>>> base weston-init recipe -- our touchscreen auto-configuration script.
>>>>
>>>> That script has to have root access to setup and reload udev rules 
>>>> and as we know setuid won't work for shell scripts.
>>>>
>>>> I propose we rewrite it in something that can use setuid (perl or c 
>>>> or something of the sort). I'm currently looking at perl as there's 
>>>> already quite a few core recipes that rdepend on it.
>>>>
>>>> Then we just need to inject it into the runWeston script and adjust 
>>>> the two init scripts to point at that.
>>>>
>>>> Any concerns or objections?
>>>
>>> Why not just drop out that old touchscreen script, it is a 
>>> non-standard way of doing
>>> this task and should be removed.
>>>
>>> Andrew
>>
>> It's non-standard, but that's because there really isn't a good 
>> standard for calibrating touch screens under Weston. AFAIK this is 
>> still useful.
> 
> https://wiki.st.com/stm32mpu/wiki/How_to_calibrate_the_touchscreen
> 
> This seems like the standard ^^
> 
> Andrew

That does save the config for the user running weston. Currently our 
script saves and loads the config for all users. This could technically 
be seen as a regression, but it doesn't seem that bad to me.

Re: [DISCUSSION] Weston-Init and non-root weston

[Andrew Davis]

On 4/17/23 6:01 PM, Randolph Sapp wrote:
> On 4/17/23 17:52, Andrew Davis wrote:
>> On 4/17/23 5:43 PM, Randolph Sapp wrote:
>>> On 4/17/23 17:39, Andrew Davis wrote:
>>>> On 4/17/23 5:32 PM, Randolph Sapp wrote:
>>>>> Finally getting around to weston-init issue I highlighted a while back and there's only one real issue preventing us from reusing the base weston-init recipe -- our touchscreen auto-configuration script.
>>>>>
>>>>> That script has to have root access to setup and reload udev rules and as we know setuid won't work for shell scripts.
>>>>>
>>>>> I propose we rewrite it in something that can use setuid (perl or c or something of the sort). I'm currently looking at perl as there's already quite a few core recipes that rdepend on it.
>>>>>
>>>>> Then we just need to inject it into the runWeston script and adjust the two init scripts to point at that.
>>>>>
>>>>> Any concerns or objections?
>>>>
>>>> Why not just drop out that old touchscreen script, it is a non-standard way of doing
>>>> this task and should be removed.
>>>>
>>>> Andrew
>>>
>>> It's non-standard, but that's because there really isn't a good standard for calibrating touch screens under Weston. AFAIK this is still useful.
>>
>> https://wiki.st.com/stm32mpu/wiki/How_to_calibrate_the_touchscreen
>>
>> This seems like the standard ^^
>>
>> Andrew
> 
> That does save the config for the user running weston. Currently our script saves and loads the config for all users. This could technically be seen as a regression, but it doesn't seem that bad to me.

Better question than does it provide "any benefit at all": Does the
benefit outweigh the hacky-ness and effort needed to maintain
and document it?..

Andrew

Re: [DISCUSSION] Weston-Init and non-root weston

[Randolph Sapp]

On 4/17/23 18:08, Andrew Davis wrote:
> On 4/17/23 6:01 PM, Randolph Sapp wrote:
>> On 4/17/23 17:52, Andrew Davis wrote:
>>> On 4/17/23 5:43 PM, Randolph Sapp wrote:
>>>> On 4/17/23 17:39, Andrew Davis wrote:
>>>>> On 4/17/23 5:32 PM, Randolph Sapp wrote:
>>>>>> Finally getting around to weston-init issue I highlighted a while 
>>>>>> back and there's only one real issue preventing us from reusing 
>>>>>> the base weston-init recipe -- our touchscreen auto-configuration 
>>>>>> script.
>>>>>>
>>>>>> That script has to have root access to setup and reload udev rules 
>>>>>> and as we know setuid won't work for shell scripts.
>>>>>>
>>>>>> I propose we rewrite it in something that can use setuid (perl or 
>>>>>> c or something of the sort). I'm currently looking at perl as 
>>>>>> there's already quite a few core recipes that rdepend on it.
>>>>>>
>>>>>> Then we just need to inject it into the runWeston script and 
>>>>>> adjust the two init scripts to point at that.
>>>>>>
>>>>>> Any concerns or objections?
>>>>>
>>>>> Why not just drop out that old touchscreen script, it is a 
>>>>> non-standard way of doing
>>>>> this task and should be removed.
>>>>>
>>>>> Andrew
>>>>
>>>> It's non-standard, but that's because there really isn't a good 
>>>> standard for calibrating touch screens under Weston. AFAIK this is 
>>>> still useful.
>>>
>>> https://wiki.st.com/stm32mpu/wiki/How_to_calibrate_the_touchscreen
>>>
>>> This seems like the standard ^^
>>>
>>> Andrew
>>
>> That does save the config for the user running weston. Currently our 
>> script saves and loads the config for all users. This could 
>> technically be seen as a regression, but it doesn't seem that bad to me.
> 
> Better question than does it provide "any benefit at all": Does the
> benefit outweigh the hacky-ness and effort needed to maintain
> and document it?..
> 
> Andrew

I would say no, it doesn't outweigh the hacky-ness. Our script 
force-reloads Weston adding an unnecessary delay for every recalibration.

Denys, any input here? Anyone you know of expecting this behavior 
downstream?

Re: [DISCUSSION] Weston-Init and non-root weston

[Denys Dmytriyenko]

On Mon, Apr 17, 2023 at 06:16:19PM -0500, Randolph Sapp wrote:
> On 4/17/23 18:08, Andrew Davis wrote:
> >On 4/17/23 6:01 PM, Randolph Sapp wrote:
> >>On 4/17/23 17:52, Andrew Davis wrote:
> >>>On 4/17/23 5:43 PM, Randolph Sapp wrote:
> >>>>On 4/17/23 17:39, Andrew Davis wrote:
> >>>>>On 4/17/23 5:32 PM, Randolph Sapp wrote:
> >>>>>>Finally getting around to weston-init issue I
> >>>>>>highlighted a while back and there's only one real issue
> >>>>>>preventing us from reusing the base weston-init recipe
> >>>>>>-- our touchscreen auto-configuration script.
> >>>>>>
> >>>>>>That script has to have root access to setup and reload
> >>>>>>udev rules and as we know setuid won't work for shell
> >>>>>>scripts.
> >>>>>>
> >>>>>>I propose we rewrite it in something that can use setuid
> >>>>>>(perl or c or something of the sort). I'm currently
> >>>>>>looking at perl as there's already quite a few core
> >>>>>>recipes that rdepend on it.
> >>>>>>
> >>>>>>Then we just need to inject it into the runWeston script
> >>>>>>and adjust the two init scripts to point at that.
> >>>>>>
> >>>>>>Any concerns or objections?
> >>>>>
> >>>>>Why not just drop out that old touchscreen script, it is a
> >>>>>non-standard way of doing
> >>>>>this task and should be removed.
> >>>>>
> >>>>>Andrew
> >>>>
> >>>>It's non-standard, but that's because there really isn't a
> >>>>good standard for calibrating touch screens under Weston.
> >>>>AFAIK this is still useful.
> >>>
> >>>https://wiki.st.com/stm32mpu/wiki/How_to_calibrate_the_touchscreen
> >>>
> >>>This seems like the standard ^^
> >>>
> >>>Andrew
> >>
> >>That does save the config for the user running weston. Currently
> >>our script saves and loads the config for all users. This could
> >>technically be seen as a regression, but it doesn't seem that
> >>bad to me.
> >
> >Better question than does it provide "any benefit at all": Does the
> >benefit outweigh the hacky-ness and effort needed to maintain
> >and document it?..
> >
> >Andrew
> 
> I would say no, it doesn't outweigh the hacky-ness. Our script
> force-reloads Weston adding an unnecessary delay for every
> recalibration.
> 
> Denys, any input here? Anyone you know of expecting this behavior
> downstream?

There's always a balance between doing things generically and making things 
very user friendly. Finding such balance is not easy - the pendulum has been 
swinging back and forth through the years...

This was one of the earliest out-of-box user experience additions to TI 
SDKs and has been relied upon by downstream products. I don't have strong 
objections for removing this custom code, but you might want to check with 
the corresponding product SDK teams.

-- 
Denys

Re: [EXTERNAL] Re: [DISCUSSION] Weston-Init and non-root weston

[Randolph Sapp]

On 4/18/23 17:51, Denys Dmytriyenko wrote:
> On Mon, Apr 17, 2023 at 06:16:19PM -0500, Randolph Sapp wrote:
>> On 4/17/23 18:08, Andrew Davis wrote:
>>> On 4/17/23 6:01 PM, Randolph Sapp wrote:
>>>> On 4/17/23 17:52, Andrew Davis wrote:
>>>>> On 4/17/23 5:43 PM, Randolph Sapp wrote:
>>>>>> On 4/17/23 17:39, Andrew Davis wrote:
>>>>>>> On 4/17/23 5:32 PM, Randolph Sapp wrote:
>>>>>>>> Finally getting around to weston-init issue I
>>>>>>>> highlighted a while back and there's only one real issue
>>>>>>>> preventing us from reusing the base weston-init recipe
>>>>>>>> -- our touchscreen auto-configuration script.
>>>>>>>>
>>>>>>>> That script has to have root access to setup and reload
>>>>>>>> udev rules and as we know setuid won't work for shell
>>>>>>>> scripts.
>>>>>>>>
>>>>>>>> I propose we rewrite it in something that can use setuid
>>>>>>>> (perl or c or something of the sort). I'm currently
>>>>>>>> looking at perl as there's already quite a few core
>>>>>>>> recipes that rdepend on it.
>>>>>>>>
>>>>>>>> Then we just need to inject it into the runWeston script
>>>>>>>> and adjust the two init scripts to point at that.
>>>>>>>>
>>>>>>>> Any concerns or objections?
>>>>>>>
>>>>>>> Why not just drop out that old touchscreen script, it is a
>>>>>>> non-standard way of doing
>>>>>>> this task and should be removed.
>>>>>>>
>>>>>>> Andrew
>>>>>>
>>>>>> It's non-standard, but that's because there really isn't a
>>>>>> good standard for calibrating touch screens under Weston.
>>>>>> AFAIK this is still useful.
>>>>>
>>>>> https://wiki.st.com/stm32mpu/wiki/How_to_calibrate_the_touchscreen
>>>>>
>>>>> This seems like the standard ^^
>>>>>
>>>>> Andrew
>>>>
>>>> That does save the config for the user running weston. Currently
>>>> our script saves and loads the config for all users. This could
>>>> technically be seen as a regression, but it doesn't seem that
>>>> bad to me.

Whoops, that does not save the config for the user, it just applies it 
for the session. We'll still need a script to launch the calibrator on 
detection of a touch screen, and a helper script to hook into the 
calibration_helper [1].

[1] https://man.archlinux.org/man/weston.ini.5.html#calibration_helper=