Hi everyone,

I finally managed to install obarun on my laptop.
I am still looking into how this 66-thing work but I wanted to anticipate on something else.

I have a surface pro (7+) and I would like to have the touchscreen working.

thanks to
https://github.com/linux-surface/iptsd
and
https://github.com/quo/ithc-linux
I could get the touchscreen functional with a previous Arch Install

the thing is that it relies on systemd; would it be possible to " DIY some hooks " to make it work with s66 or that something impossible for a newbe ?

-->"At the moment, only systemd based distributions are properly supported. The daemon itself does not depend on the service manager in any ways, but it needs to know which hidraw device corresponds to the touchscreen. The easiest way to do this is with udev and a parameterized service file, which only systemd seems to support."

[well I am not asking anyone to help me doing it before I even try myself,
but if 5 minutes of your time is enough to tell me if it is NO GO ... it will be much apreciated]

Thanks
Hi and welcome

First we are talking about an input device with an xy range guided by the screen resolution as the hw part. So all the kernel sees is a funky mouse. The software part that manipulates this input and configures its use is the secondary part. So it is not as complicated as it sounds initially.
The systemd only fluff is just propaganda, don't buy into it. You just have to spend a few minutes to write a service file for any other init for "that software" iptsd which is not even an official arch pkg but something someone has added to the community AUR repository. I am sure when it receives adequate amount of votes as popularity indicator it will move into community or extra.
You can just comment the line that adds the service file and the pkg will build fine, systemd is not a real dependency to it. But even if the service file is installed in your system it will not affect its use.
[Unit]
Description=Intel Precise Touch & Stylus Daemon
Documentation=https://github.com/linux-surface/iptsd
StopWhenUnneeded=yes
BindsTo=%I

[Service]
Type=simple
ExecStart=@ bindir@ /iptsd %I
The service file basically says you run as root iptsd interface name , which since I've never had a touch screen I don't what it would be like. I am sure Eric can take 2.4' to write a module type service file for it. The interface name you may get from lspci or lsusb depending how the chip for it is listed in the hw structure, but since I don't have one yet I can't help you. You may run lsusb and see it listed as something like ts0 or ts1 so the service command would be iptsd ts1, and if you have a service file written for it

# 66-enable -FS iptsd@ ts1
would get it enabled and running right away.

Now, I see 2-3 areas of issues with this, as touch screen in general is not a very common device around linux but with amd64 architecture based tablets growing and becoming cheaper I can see it catching on.
First, the kernel has to be built with that particular touch-screen hw device being enabled, or the specific module for it has to be added to the kernel's coverage. I'd give better than 50% chance that arch kernels have an MS touch screen device turned on.
2nd issue may relate to resolution, and many of those devices list an amazing resolution for something 11-13" big, when it is even hard to tell the difference with 1920x1080/1200 in a 24-30" screen. I think, not sure, but such resolution levels are fake yet, and the effective real resolution is still less than listed. On an "input device" that uses resolution as its input range that may be a can of worms.
3rd part is to get to this configuration and installation for that one time you'll set it up you might need a physical keyboard, which will have to connect through one of your usb ports, and I don't know whether you have one. Otherwise a system with an sshd service running that you can access from an other pc on your network may have to act as a terminal to the tablet.

Interesting platform, still pretty pricey, but if you need to have an i7 stored under the rear seat of your motorcycle running obarun it may be a good thing :) and when you leave the autobahn type of hwy to climb around a mountain you can alter the injection maps from economy to performance, or for having an emissions' test done.

For the rest of us a 2-4 core amd tower for 80$ will have to suffice.
Linux6.0 no longer supports AT input devices, a hook for an extra module will have to be added to use one of those pre-historic clunky indestructible keyboards, heavy enough so your fingers don't have to chase the keyboard around the table (if you have a table and don't do all your programming on your knees. :)
I also found this interesting response to a question of not finding the device by lspci or lsusb


The reason lsusb or lspci don't show the touchpad is that the device is not connected directly to USB or PCI. It is connected to i2c bus.

You can see it in Sysfs=/devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-2/i2c-06CB:00/0018:06CB:1A1B.0002/input/input14

The i2c controller is connected to the PCI bus and you can see it too.

00:15.0 Serial bus controller [0c80]: Intel Corporation Serial IO I2C Host Controller
00:15.1 Serial bus controller [0c80]: Intel Corporation Comet Lake Serial IO I2C Host Controller

Thank you for your help.

tbh I did not understand 100% of what you wrote but I guess that's good excuse for me to dive into S66 uses.
will try to detail step I did to make it work (or not work)
Skatanafas wrote 3rd part is to get to this configuration and installation for that one time you'll set it up you might need a physical keyboard, which will have to connect through one of your usb ports, and I don't know whether you have one. Otherwise a system with an sshd service running that you can access from an other pc on your network may have to act as a terminal to the tablet.
it was a concern that a traditional keyboard would be needed for installation, this is not the case, sounds like modern kernels you will find in most live iso support the overpriced surface keyboard out of the box. touchscreen is the real only thing that do not work out of the box (did not try webcam though)
Skatanafas wrote 2nd issue may relate to resolution, and many of those devices list an amazing resolution for something 11-13" big, when it is even hard to tell the difference with 1920x1080/1200 in a 24-30" screen.
the first related issue is that everything bloody small on tty and on DE from live iso.
If you allow me suggestion, I think that adding this : 
setfont solar24x32.psfu.gz

in the install wiki would help a lot of people like me (or can I actually add it myself ?)
Skatanafas wrote Interesting platform, still pretty pricey, but if you need to have an i7 stored under the rear seat of your motorcycle running obarun it may be a good thing smile and when you leave the autobahn type of hwy to climb around a mountain you can alter the injection maps from economy to performance, or for having an emissions' test done.

For the rest of us a 2-4 core amd tower for 80$ will have to suffice.
I have to agree that 90% of the time it is gimmick but the last 10% that's great (worthy is another thing)
otherwise the 6h autonomy and the noiseless aspect is a real comfort.
Before you dive in to s6/66, simplified comparison of init, service management, and service supervision.
sysvinit --> dynosaur of unix system remains
openRc --> an evolved dynosaur into tiny lizzards
runit --> birth of a new specie --> simplistic - adequate - maybe

systemd --> DNA from a dynosaur going rogue and forming a huge pile of cancer
s6 --> what runit couldn't achieve or perform but better/faster/precise - will be here long after systemd will be abandoned like comparing calculators (runit) computers (s6) to an abacus (systemd).
66 --> manage s6 for common mortals because only specialized computer scientists/researchers can appreciate and handle s6 directly.

Some fools, including passing by obarun users, think of s6/66 as a cheap alternative to systemd that has not yet evolved.

runit scripts for services like dhcpcd or wpa_supplicant or dbus are small bash scripts stored usually in etc/sv or etc/runit/sv or usr/lib/runit or usr/share/runit, in similar fashion 66 scripts can be stored in such places designated 66/services they are more readable and understandable than runit's and execute faster while taking less resources by s6 to supervise (basically knowing when to start, stop, or restart a program/daemon/service).

Say you write a program called time, which rings up a time server on the net, gets the UTC time of the server, adds/subtracts x-hours for your timezone, and send its output in a conky on your screen of what time it is. Every y-minutes it repeats this till you kill the program.
You can execute this once and expect it to run for ever, but it doesn't, a brief period of net interruption would produce a fail to reach server and you have told the program if it fails 3 times to end sending an error 345 indicating the failure to reach server.
A Runit script specifies when should runit restart the program when it fails, when to stop it and how to stop it, and each time it runs this bash script checking if everything is ok.
s6 does the same, doesn't use bash (too slow and resource consuming, too general of a tool made for many uses) but execline, and does what runit does, much faster and frequent, running on fumes of resources. For every service runit runs an runsvdir program that does the supervision for that particular program, including an agetty (console service for each console), and if you have used runit you know those consoles suddenly vanish and you don't know why .... s6 runs s6-supervise which is like a MotoGP bike compared to a pre-ww2 truck (runsvdir).

Just the pride of living in a smart home (without knowing how to build and wire one) looking out of your window at the cavemen dragging wives by the hair (sysvinit/openrc), people living in a container/tent (runit), or ancient greeks/romans whipping slaves to drag huge marbles to build a "home" (systemd), is part of the pride of learning 4-5 commands to use 66. Some minimalists like tents, except for when there is a blizzard or hail, and slavery can be good, if you are not one yourself, but bragging about the superiority of the parthenon or the colosseum to caves like there is no 3rd alternative gets really old and boring.

Your evolved atom hardware, is noisless/fanless, but you have to ask yourself why do same class CPUs use such cooling systems still on desktops/towers. Don't play games too long, or compile gcc too often, or you may find out, while that aluminum casing is not an aesthetic choice of materials, it substitutes cooling fins and fans. So don't lay it on your pillow while computing heavily.

The older you get the more you can appreciate the white noise of a fan (hardly noticeable these days) because it blocks the noise in your head which you will eventually get in your 50s with partial loss of hearing. If you attend too many concerts or live shows in clubs the past 2 decades you may even get that in your 40s.

- punkznotdead
back to your problem:

I would try a keyboard/mouse from any amd/intel desktop with a usb/microusb or usb-c converter
If you find one of those converters with 2-3-4 USB to microusb/usb-c you can plug both mouse and keyboard into that little usb port ... I am 90% sure it will work, no need to buy that expensive accessory, or borrow one just for the installation.

Another try is to make an openbox/jwm installation into a usb stick and add fingerterm or similar pkg, add fingerterm to ~/.config/jwm/start or ~/.config/openbox/autostart and do the installation using that keyboard. You can later try other variations of fingerterm from AUR to suit your needs.

Make sure you have obarun-install installed in that usb stick system.

Also try terminus-font and set your module without ! to ter-u32b for large clear console font.

Powered by Obarun