Acer Spin 1 (опыт установки Ubuntu 18.04)

[zg_nico]

Приветствую, уважаемые формучане и гости форума. Данный пост создан ввиду некоторых трудностей, с которыми я столкнулся при попытке установить Ubuntu 18.04 по состоянию на 28.03.18 на ноутбук Acer Spin 1 (ранее поднимал уже эту тему, но грабли оказались интересными в моем понимании, - спешу поделиться тем, что заработало). Надеюсь, кому-то будет полезна данная информация.

(Нажмите, чтобы показать/скрыть)

Уважаемые модераторы, искренне прошу с пониманием отнестись, если я в чем-то не соответствую данной темой правилам форума. Однако на текущий момент времени информации по ноутбукам с сенсорными экранами не так много, и, мне кажется, данный пост может сэкономить кучу времени некоторым новым пользователям. Заранее искреннее спасибо за понимание

(Нажмите, чтобы показать/скрыть)

Если по-русски: процессор Intel Pentium N4200, объём ОЗУ 4 Гб, встроенной ПЗУ: 64Гб (при этом все, вплоть до ОЗУ и ПЗУ распаяно на материнке - ничего в нетбуке заменить НЕЛЬЗЯ). И это не реклама или антиреклама - это констатация факта. Считаю необходимым донести информацию до людей.
Выхлоп sudo lshw привожу во вложении, ибо много. Выхлоп lscpu прицеплю здесь, ибо еще терпимо.

Архитектура:         x86_64
CPU op-mode(s):      32-bit, 64-bit
Порядок байт:        Little Endian
CPU(s):              4
On-line CPU(s) list: 0-3
Потоков на ядро:     1
Ядер на сокет:       4
Сокетов:             1
NUMA node(s):        1
ID прроизводителя:   GenuineIntel
Семейство ЦПУ:       6
Модель:              92
Имя модели:          Intel(R) Pentium(R) CPU N4200 @ 1.10GHz
Степпинг:            9
CPU МГц:             1556.222
CPU max MHz:         2500,0000
CPU min MHz:         800,0000
BogoMIPS:            2188.80
Виртуализация:       VT-x
L1d cache:           24K
L1i cache:           32K
L2 cache:            1024K
NUMA node0 CPU(s):   0-3
Флаги:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology tsc_reliable nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg cx16 xtpr pdcm sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave rdrand lahf_lm 3dnowprefetch cpuid_fault cat_l2 pti tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust smep erms mpx rdt_a rdseed smap clflushopt intel_pt sha_ni xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts

Особенности установки Ubuntu на данном устройстве. К сути топика. Прежде всего, замечу, что установку вел в дуалбут. Ноутбук НЕ УМЕЕТ legacy. Есть только UEFI. Попал ко мне с установленной оффтоповой системой на весь внутренний диск (крайне малого объема), так что пришлось импровизировать.

(Нажмите, чтобы показать/скрыть)

Первым делом - под форточками следует выполнить удаление всей лишней требухи, дабы высвободить место. Второе - выполнить дефрагментацию. Желательно даже не стандартными средствами оффтоповой системы (еще желательней - с какой-нибудь live сборки, дабы не возникало траблов с неперемещаемыми системными файлами). Далее следует войти в меню UEFI settings (на данной модели - СОЧЕТАНИЕ клавиш Fn+F2 в начале загрузки, когда увидели логотип Acer; после чего ставим пароль на UEFI (и запоминаем его себе, чтоб понимать что вводить после), после чего на соответствующей вкладке станет доступным изменение параметра SecureBoot), где выключаем параметр SecureBoot, и выходим, сохранив настройки. После этого я вставил заранее подготовленную через multibootUSB флешку, содержащую загрузочный образ Ubuntu 18.04.
После отключения SecureBoot загрузка происходит штатно. В Live удается зайти. Однако здесь нас ждет одна из трудностей, которую предстоит решить далее - экран повернут вправо. Дело в том, что ноутбук снабжен акселерометром, и этот акселерометр не корректно откалиброван. Чтобы комфортно работать на данном этапе поворачиваем ноут (физически) на левый бок (при этом изображение будет выровнено так, будто ноут стоит на столе в нормальном положении), и, не поворачивая ноута, в меню пользователя (искать в правом верхнем углу для GNOME3) кликаем по кнопке с замочком (вторая слева), - так поворот будет заблокирован. Ставим ноут на стол, и изображение пока больше не крутится... Можно проверить функциональные клавиши, - все работают. А вот F1-12 пользоваться не удобно, т.к. только в сочетании с Fn они будут работать. Иными словами тот же переход в консоль (tty1) уже не Ctrl+Alt+F1 а Ctrl+Alt+Fn+F1 (такое ощущение, будто на пианино новую гамму разучиваешь...).
1. Установка. Места у нас не так много, - на отдельные home и прочее особо не разоришься. Так что будем импровизировать. Исходная разметка диска, как ее видит blkid:

/dev/mmcblk1: PTUUID="3aa7461f-e6be-48f2-a064-61b3fb1c73e0" PTTYPE="gpt"
/dev/mmcblk1p1: LABEL="ESP" UUID="1026-DB48" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="86f70c5b-8a21-4147-ac95-f909b69395e0"
/dev/mmcblk1p2: PARTLABEL="Microsoft reserved partition" PARTUUID="2a24fd22-d8fe-4905-81b8-1c847fe8803e"
/dev/mmcblk1p3: LABEL="Acer" UUID="B0622B51622B1C1A" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="5475443d-6ae7-4816-abdb-a834d193ae41"
/dev/mmcblk1p4: LABEL="Recovery" UUID="E6382C12382BDFF3" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="632708f5-9337-4a59-9e54-0badebf1de7c"

Имеем раздел рековери. Неплохо бы сохранить. Особенно с учетом того, что данный раздел в устройстве функционирует "лояльно" по отношению к внесению пользователем изменений в разметку диска, - размер тома, на котором установлена Windows при восстановлении ее к состоянию, зашитому в recovery, не меняется на исходный. Для начала неплохо выполнить резервирование имеющегося состояния разделов: подключаем внешний жесткий диск (или флешку хорошего такого объема, - у меня образы заняли в итоге ~12Гб, если в Windows что-то установлено - то будет больше!), и выполняем в терминале такие команды (в данном случае /media/Maxtor - точка монтирования моего внешнего жесткого диска, куда я все резервирую; все разделы на mmcblk1 у меня ОТМОНТИРОВАНЫ):

Код: [Выделить]

dd if=/dev/mmcblk1p1 | gzip - | dd of=/media/Maxtor/Image_mmcblk1p1.img.gz
dd if=/dev/mmcblk1p2 | gzip - | dd of=/media/Maxtor/Image_mmcblk1p2.img.gz
dd if=/dev/mmcblk1p3 | gzip - | dd of=/media/Maxtor/Image_mmcblk1p3.img.gz   #делается ДОЛГО, но он нам нужен очень
dd if=/dev/mmcblk1p4 | gzip - | dd of=/media/Maxtor/Image_mmcblk1p4.img.gzНа этом этапе успокаиваемся, т.к. резервная копия у нас есть. Извлекаем внешний жесткий диск, и откладываем в сторону... Надеюсь, не понадобится. При необходимости соответствующий раздел можно будет восстановить по аналогии (следим за размером! Выхлоп sudo fdisk -l лучше сохранить поблизости с образами):

Код: [Выделить]

dd if=/media/Maxtor/Image_mmcblk1p3.img.gz | gunzip - | dd of=/dev/mmcblk1p3Далее я открыл gparted, и внес изменения в разметку диска, отрезав от mmcblk1p3 22 Гб. На этом пустом месте был создан раздел mmcblk1p5 размером 22 Гб; формат - ext4. Применив изменения, я перезагрузился в Windows и убедился в том, что она работает (если нет - тут надо в LIVE возвращать разделу mmcblk1p3 его исходное состояние, удалив mmcblk1p5 и накатив его [mmcblk1p3] прежнее состояние из образа). Если на данном этапе все в норме - идем дальше.

Загружаемся в live. Запускаем с рабочего стола значок установки системы. Ставим как обычно. Можно сейчас качать обновления - можно не качать. При установке выбираем раздел mmcblk1p5 в качестве "/", раздел с Windows можно прописывать или не прописывать - на Ваше усмотрение. Раздел mmcblk1p1 указываем как хранилище загрузчиков EFI, а для установки GRUB указываем устройство mmcblk1 (не разделы, а само устройство). Запускаем установку. Через непродолжительное время она подойдет почти к концу (пропишет, что выполняется установка GRUB-2), и... зависнет (минут 10 до меня это доходило). Да. Пиечалька... Не отчаиваемся на этом этапе. Поскольку я не был уверен почему эта котовасия происходит, я выполнил завершение работы программы установки: sudo killall ubiquity, и, желая проверить насколько все плохо, попробовал запустить инсталлятор без установки загрузчика (как выяснилось позже, он-то встал, но вот с Secure-Boot какая-то заморочка). Для этого я нашел ярлык программы установки на рабочем столе, и в свойствах этого ярлыка (где указаны параметры запускаемой им программы) добавил к имеющимся параметрам параметр "-b", после чего запустил программу установки с этого ярлыка, выставил все, как это делал в первый раз, раздел с mmcblk1p5 не форматировал. На сей раз установка прошла полностью, заминок не возникло. Понимая, что, походу, уже не все так просто, я выполнил blkid, из выхлопа которого выписал себе на листок UUID диска mmcblk1p5, после чего перезагрузился. При загрузке вошел в UEFI Settings, увидел там пункт загрузки "неизвестное устройство", добавил его в список доверенных, обозвав GRUB (указал в качестве доверенного бинарника файл по адресу /EFI/ubuntu/grubx64.efi, для чего пришлось сперва вновь включить Secure-Boot), выставил его в приоритете раньше двух (внезапно) копий загрузчика windows. Выполнив все это - я покинул меню UEFI Settings и попытался загрузиться в свежеустановленную ubuntu. Меня встретил grub-rescue, приветливо мерцая квадратным курсором. Не особо горя желанием лезть в сеть в поисках ответа, я посмотрел строки, которые прописаны у меня на втором ноуте в grub.cfg, и, с поправками, списал себе "загружалку". Для этого в консоли GRUB-rescue последовательно были введены команды (версия ядра - на момент установки; к релизу поменяется; при вводе пользоваться автодополнением по TAB):

Код: [Выделить]

insmod part_gpt
insmod ext2
set root='hd0,gpt5' #(мой раздел с системой был пятым на первом диске: mmcblk1p5)
linux /boot/vmlinuz-4.15.0-12-generic.efi.signed root=UUID=32a2d3ad-c8e4-4808-8462-186e364730b7 ro #(UUID=многобукафф - это UUID раздела номер 5; его надо брать из вывода blkid в LIVE - способы его получения прямо в grub [если таковые имеются] мне не известны)
initrd /boot/initrd.img-4.15.0-12-generic
bootПосле ввода последней команды система пошла загружаться. Естественно, с загрузчиком была какая-то байда, и я не был уверен как это решать.

(Нажмите, чтобы показать/скрыть)

Сперва выполнил в системе попытку (ладно: несколько попыток, в т.ч. и с применением Boot-Repair) установить grub2. Набор ошибок говорил о каком-то странном сбое все время в разном месте. После очередной безуспешно зависшей попытки установки загрузчика попробовал выполнить sudo update-grub, и все пробежало без ошибок. Образы нашлись, все в ажуре, загрузочный конфиг создался. Перезагрузился - увидел типичное меню Grub2, порадовался даже. Но далее решил заняться настройкой системы, и выполнить обновления. При обновлении прилетело новое ядро. Наличие нового ядра привело к переформированию grub'овского конфига (а похоже еще и отсылок к бинарникам EFI), и на каком-то этапе все снова встало колом. Для чистоты эксперимента я заново снес все, заново поставил систему, и получил те же грабли в том же месте. Прикинув, как будет пользователь мучаться с этой девайсиной, я поплевался, и решил прибегнуть к альтернативным загрузчикам.

В соответствии с заспойлеренными выводами, мне пришлось задуматься о смене загрузчика. Выбор пал на rEFInd. Установил его, скачав deb-пакет. rEFInd встал без сбоев. В меню UEFIsettings вновь задействовал SecureBoot, ввел пароль на UEFI, и указал в качестве доверенного файл \EFI\refind\refind_x64.efi, перезагрузился, поменял приоритет загрузки таким образом, чтобы rEFInd загружался первым. Загрузка без сбоев - загрузчик появляется на экране сразу же, только грузить он пытается не Ubuntu а GRUB, а это не кошерно как-то... Для исправления этого несуразного поведения в установленной системе было принято решение начисто снести GRUB как таковой:

Код: [Выделить]

sudo apt purge grub-efi-amd64 grub-efi-amd64-signed grub-common grub-efi-amd64-bin grub-common grub2-common shim-signed mokutil os-prober secureboot-db shim Далее установил по рекомендации товарища бамбук пакет-пустышку grub-3.0. После этого дело вроде как пошло. После перезагрузки вход сразу в Ubuntu из загрузчика, - GRUB уже самовольно не стартует (да и нету его, строго говоря, в первозданном виде). Так пришлось заменить родной GRUB2 на rEFInd. Его, говорят, тоже конфигурировать можно, - так что ладно уж. Переживем.

(Нажмите, чтобы показать/скрыть)

мною было проверено обновление ядра при rEFInd, - без сучка и задоринки, все прошло гладко и без запинок

Необязательное (и опасное по сути своей) дополнение: меня раздражали дополнительные загрузочные бинарники, которые находил rEFInd, и самым быстрым способом заставить его их не находить мне показалось их удаление. Корректным был бы вариант через efibootmgr, но лень взяла свое (тем более, что образ раздела с ESP лежит в бэкапе на случай чего), и я прибегнул к вот такому хардкору:

Код: [Выделить]

sudo rm -R /boot/efi/EFI/BOOT #лежал тут еще один загрузичк Windows - мне как бы и одного хватит за глаза...
sudo rm /boot/efi/EFI/ubuntu/grubx64.efiПосле этого запустил efibootmgr, удостоверился, что все вроде как надо. При перезагрузке сбоев не получил, вытер холодный пот и возрадовался.
Решение проблем с автоповоротом экрана. Далее настал черед поворота экрана Spin 1, который не работет (работает инверсно, не так, как задумано). После долгого гугления и мыканий было найдено решение на основании прописанного здесь. Для решения необходимо и достаточно сделать следующее:
1. Устанавливаем необходимые пакеты:

Код: [Выделить]

sudo apt install iio-sensor-proxy inotify-tools 2. Создаем и заполняем конфигурационный файл:

Код: [Выделить]

sudo gedit /etc/udev/hwdb.d/61-sensor-local.hwdbВ открывшемся пустом окне вбиваем текст:

#########################################
# Acer Spin 1 SP111-32N
#########################################
sensor:modalias:acpi:BOSC0200*:dmi:*Acer*Spin*
 ACCEL_MOUNT_MATRIX=0, 1, 0; 1, 0, 0; 0, 0, 1

(шаблоны состряпаны после прочтения выхлопа udevadm info --export-db и sudo lshw, в которых искались этот самый сенсор [acpi] и определение самого ноутбука [dmi])
3. Применяем изменения:

Код: [Выделить]

sudo systemd-hwdb update
sudo udevadm trigger -v -p DEVNAME=/dev/iio\:device04. Перезагружаемся.
Теперь можно открыть залоченный ранее в меню пользователя GNOME3 (да, я не знаю как оно правильно называется - я это DE вижу третий раз в жизни) автоповорот, и, покрутив ноут, убедиться, что гироскоп нормально работает (и это хорошо, что подошла конфигурация от родственного [в смысле единовендорного] устройства, т.к. я попытался попереставлять параметры произвольным образом и началась совершенная чертовщина в поведении гироскопа, - как настроить, так и не разобрался; назовем это везением).
Что пока не победил:
1. Встроенный карт-ридер странным образом себя ведет. Карта памяти, если ее оставить в карт-ридере, и пререзагрузить ноутбук, не определяется системой. dmesg при этом завален ошибками вида (время специально прописал, - примерно понятно как часто они высыпаются и что их реально тьма):

...
[   40.814790] mmc0: Skipping voltage switch
[   40.851113] mmc0: Skipping voltage switch
...

Если в карт-ридере ничего нет, то при загрузке в dmesg чисто. И вставленная в уже загруженной системе карточка определяется нормально. На данный момент "ковыряю". Обновлю пост как пойму, с чем связано такое поведение.

[andytux]

Запускаем установку. Через непродолжительное время она подойдет почти к концу (пропишет, что выполняется установка GRUB-2), и... зависнет

Похоже, для Acer-ов это становится нормой:
https://forum.ubuntu.ru/index.php?topic=290942.msg2288952#msg2288952

[zg_nico]

andytux, не только у Acer. Тут в соседней теме на Lenovo IdeaPad 320-15 (хотя по железу в сущности - похож на сабж) у человека такая же проблема... Занятно, что это действительно вводит в ступор. Меня, по крайней мере, ввело. До этого где только не пользовал Ubuntu и Knoppix - главное было Live запустить, дальше ни одной проблемы не припомню в принципе. А с таким вот поведением столкнулся впервые. Наверное, комплексная причина: с одной стороны, вендор в целях экономии вместо установки SSD на материнской плате какую-то флеш-память распаял (с не самыми впечатляющими характеристиками производительности, стоит заметить, - примерно как у путнего IDE-диска). С другой стороны - какая-то особенная реализация SecureBoot, приводящая на практике к невозможностью отключения данной опции (когда он выключен, он, по сути, все равно включен). Остается надеяться, что производители рано или поздно перестанут дурью маяться, и начнут выпускать-таки адекватные устройства, а не эти недоделки.
Пользователь добавил сообщение 01 Апреля 2018, 22:36:59:Как говорил Карлсон, "продолжаем разговор"... К вопросу о работе тач-скрина. Как я ни пытался гуглить на тему его калибровки - ничего особо путнего не нашел. Сам тач работает. При этом поведение DE при манипуляциях с тачем интуитивно понятным не назовешь. Например, левая панель GNOME: если ткнуть по любому приложению дважды, приложение откроется. Если вытащить туда gedit или nautilus - они открывают сразу два окна. Если ткнуть на кнопку "Все приложения", - не произойдет ничего. Иногда приложения показываются, иногда - нет. Если при этом нажать пальцем, и, не отпуская, протянуть палец в направлении рабочего стола (вправо), - меню приложений появляется. Ковырял "Параметры" -> "Специальные возможности". Активировал "Наведение и нажатие" -> "Клавиши мыши"; там же в подразделе "Помощник нажатия" задействовал "Вторичное нажатие удержанием первичной кнопки", отрегулировал в сторону уменьшения время задержки. Теперь если тыкнуть куда-нибудь, и не убирать палец 8 секунд (я не знаю почему именно 8 ) - появляется контекстное меню (где оно доступно). Но снизить эту задержку до приемлимых значений (хотя бы 3 секунды) пока не нашел как.
Поставил tochegg-gce со всеми зависимостями. При любых манипуляциях с этой софтиной в поведении тачскрина не меняется ровным счетом ничего. Ни отработки жестов, ни еще каких полезностей решительным образом нет. Удалил. Опять-таки со всеми зависимостями.
По браузеру firefox: пробовал расширение ScrollAnyware в Firefox. Эффект есть, но сильно положительным его не назвать, - браузер себя ведет непредсказуемо (в качестве инициатора прокрутки приходится задействовать ЛКМ, которую эмулирует прикосновение к тач-скрину, а она на текущий момент экспериментальная, как указано в настройках самого расширения). В результате я его удалил. Помогло на удивление вот что. Если браузер запустить с указанием параметра переменной окружения, то прокрутка и выделение начинают работать так, словно пользуешься браузером на том же Android, при этом при пользовании мышью все возвращается на круги своя. Вот параметры запуска:

Код: [Выделить]

env MOZ_USE_XINPUT2=1 firefoxЧтобы прописать это по-дефолу, открываем эмулятор терминала, и выполняем:

Код: [Выделить]

sudo gedit /usr/share/applications/firefox.desktopв открывшемся файле ищем строку "Exec=firefox %u", заменяем ее на "Exec=env MOZ_USE_XINPUT2=1 firefox %u". По аналогии действуем со строками "Exec=firefox -new-window" и "Exec=firefox -private-window" Изменения сохраняем. После описанного для верности я удалил и заново создал иконку на панели запуска приложений (левая панель GNOME), и перезагрузил ноутбук.
Далее с иконки на рабочей панели или из меню приложений запускаем браузер, вбиваем в адресной строке "about:config", находим параметр "dom.w3c_touch_events.enabled" и присваиваем ему значение "1" (по-умолчанию: 2). После этого перезапускаем браузер, и убеждаемся в относительно адекватной работе тач-скрина (работают масштабирование щипком, скроллинг одним и двумя пальцами во всех направлениях, тап по ссылке как переход по ней). Не адекватна работа контекстного меню. Выделяется кусок текста. Если границы раздвинуть - перестает реагировать на нажатия на тачскрин, пока мышкой или точпадом где-нибудь не кликнешь. Потом все нормализуется. Баг по-видимому. Еще одна неприятная особенность - иногда при запуске firefox из панели приложений браузер отказывается реагировать на манипуляции с точскрином по-настроенному: будто мы ничего и не корректировали, - вместо скроллинга происходит выделение текста, переход по ссылке вообще не осуществить и т.п. Решается перезапуском браузера. При запуске из списка приложений такого бага не замечал.
Резюмируя происходящее - DE хоть и выглядит заточенным под сенсорные экраны, но на поверку не является таковым до мозга костей. Некоторые вещи происходят явно не так, как это задумано, некоторые - вообще не происходят. Однако все в рабочем состоянии. И я уверен, что если приноровиться, то и в таком режиме можно вполне себе пользоваться устройством.
Пользователь добавил сообщение 02 Апреля 2018, 06:44:39:Устал бороться с багами на Gnome3, решил накатить Ubuntu Budgee 18.04. Установил. Сконфигурировал автоповорот экрана. Заморочек меньше. Интерфейс корректно отзывается на манипуляции с тачскрином, однако ПКМ так по-прежнему и не завел. И, вероятно, не заведу. Дело в том, что нужно ровно выдерживать интервал времени, заданный настройками, как это нагуглил сегодня на geektimes. Грустно...
Еще одна проблема вскрылась: ноутбук-то трансформер. До этого я особо не тестил так называемый режим планшета. А протестировав, понял, что клавиатура и точпад отваливаются насовсем при переводе в режим планшета. И обратного перехода не происходит. Загадка, однако. Поковырял системные события. udev monitor молчит (хотя я давно осознал, что он не на все смотрит - тот же hdmi ему неведом как явление). acpi_listen говорит странные вещи. Когда крышку ноута отворачиваешь назад до предела (трансформируем в планшет), вижу вот такую кнопку:
 676AA15E-6A47-4D� 000000bc 00000000
и далее - все. Обратный перевод никакого выхлопа не генерирует. Похоже, имеем дело с отсутствием осознания ядром соответствующего acpi, а сие крайне дурно пахнет, т.к. насколько я знаю, это из "непобедимого"...

Пользователь добавил сообщение 02 Апреля 2018, 06:46:24:--------
Сейчас погуглил... Похоже, я такой не один...
Даже не знаю теперь - плакать по этому поводу, или смеяться ))

[zg_nico]

Временно вынужден приостановить свои изыскания, поскольку устройство вернулось к своему законному хозяину, коим я не являюсь. Есть на текущий момент времени несколько идей в плане "закостыливания" работы карт-ридера от момента загрузки системы и "закостыливания" поведения клавиатуры, точпада и встроенных USB-портов при переводе из режима планшета в режим ноутбука, но проверить пока никак, - как испытаю, сразу отпишусь.

[AlexBKost]

Временно вынужден приостановить свои изыскания, поскольку устройство вернулось к своему законному хозяину, коим я не являюсь.

zg_nico, пожалуй, опыты ставить будет разумнее на собственном устройстве, а то еще не известно, чего можно ожидать от законного хозяина.

[zg_nico]

AlexBKost, я вообще парень рисковый по природе своей ))
По факту - есть бэкап. Если и поломаю систему в труху - смогу откатить обратно до текущего состояния. И разумеется, всё будет делаться только с ведома и по согласию хозяина устройства.

[AlexBKost]

zg_nico, если хозяин согласен, то и рисковать нечем - можно экспериментировать.

[mimse]

Только сегодня увидел пост. Тем не менее решил продолжить и поделиться своими экспериментами с подобным устройством  от ASUS. 
Сразу  с выводов - наиболее комфортно с сенсорным экраном получилось в UNITY . 
  GNOM    приличней ведет себя в  Wayland — двойного открытия приложений нет и по нажатию на «Все приложения» все открываеться сразу.  В X — сесии  кроме проблем описанных в посте , еще проблемы в LibreOffice  с управлением в меню , нет реакции на прикосновения.   Но и в той и другой сесии были зависания после сенсорного управления.
 Во всех окружениях имитация правой кнопки получилась только  через  "Специальные возможности" , но не в 8 сек. дело, а  нажатие должно быть как в азбуке морзе точка-тире ( 1 короткое + 1 длинное).
Во всех окружениях лучше использовать
-из браузеров  Google Chrome или Opera, в обоих полная поддержка тачскрина.
- для просмотра изображений  только стандартная гномовская или Nomacs.
Автоповорот  я получил другим способом  , через скрипт в автозапуске, но на практике это оказалось не совсем удобно  на весу , из за ложных срабатываний,  не всегда горизонт выдерживается  . Я сделал скрипт на рабочем столе поворота на 180 гр.

[zg_nico]

наиболее комфортно с сенсорным экраном получилось в UNITY

16.04? У Вас там автоповорот получилось завести? Вариант со скриптом слабо устраивает, - хочется именно нативности. Я когда с флешки в 16.04 загружался, и не отрабатывал автоповорот (экран не заваливало налево, как это было в любой из 18.04) - решил, что гироскопам, наверное, 16.04 не обучена, и даже не попытался ее настроить... Наверное зря. Но время было ограничено.

[mimse]

 Да  в 16.04  со скриптом автоповорот  заработал.
  В 18.04 по умолчанию стоит iio-sensor-proxy inotify-tools , а в 16.04 его надо ставить.
А unity  , я и в 18.04 попробовал , и там с тачскрином как то все радостней .
В 18.04  , все странно,  люди пишут у них проблема ,срабатывает по умолчанию автоповорот , когда он им не нужен в стандартном ноотбуке , пытаются его выключить ,а у меня этого нет , ни какой реакции на повороты. Только тот же скрипт помогает.
Заметна разница , кроме стабильности, между Gnom  и Unity,  в реакции на трехпальцевый щипок .  Gnom  это отображение окон всех запущенных приложений, а Unity  это управление  окном активного приложения изменение размера и перемещения по экрану ( функция так себе сомнительной полезности.

[zg_nico]

Принял решение закрыть данную тему ввиду невозможности по объективным причинам продолжить эксперименты с данным ноутбуком.