!351 增加faq贡献文档

Merge pull request !351 from moshengren/dev
This commit is contained in:
moshengren 2024-08-08 02:26:53 +00:00 committed by Gitee
commit d4c267cd0c
No known key found for this signature in database
GPG Key ID: 173E9B9CA92EEF8F
44 changed files with 567 additions and 29 deletions

Binary file not shown.

After

Width:  |  Height:  |  Size: 37 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 21 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 188 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 168 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 122 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 49 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 54 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 25 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 39 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 22 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 58 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 18 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 36 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 107 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 63 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 15 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 103 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 5.9 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 67 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 14 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 109 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 14 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 108 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 17 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 60 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 57 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 79 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 15 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 162 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 62 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 519 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 202 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 386 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 25 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 17 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 20 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 405 KiB

View File

@ -0,0 +1,44 @@
# openkylin 2.0 系统监视器上新功能啦!
openKylin系统监视器是一款面向openKylin操作系统用户的桌面应用它满足了用户对于各种系统资源的监控和管理。在前面章节中我们为大家讲解介绍了openKylin系统监视器的功能作用包括处理器、交换空间、网络、磁盘、进程和服务等。今天我们就来讲一讲它即将在openKylin 2.0版本上新的那些好用功能。
## 一、最小化到托盘显示
以前大家点击右上角的“X”按钮系统监视器将直接退出现在UKUI SIG增加了最小化到托盘显示的功能点击右上角的“X”按钮会在任务栏显示一个系统监视器图标将鼠标悬浮上去可显示CPU占用率、网络上传与下载速率、内存占用率、磁盘占用率。
![](./assets/openkylin系统监视器上新功能啦/1720961153.3531778.png)
鼠标右键菜单可退出系统监视器或激活系统监视器窗口,鼠标左键单击激活系统监视器窗口。
![](./assets/openkylin系统监视器上新功能啦/1720961153.3534338.png)
## 二、处理器、内存、网络历史等详情页显示
openKylin系统监视器新增处理器、内存、网络历史三个模块的详情显示界面可以通过点击主界面左侧的处理器、内存、网络历史模块在主界面右边进行详情显示并可以通过点击右上角的“隐藏详情”按钮返回进程页面。
* 新增处理器详情页展示处理器总利用率、当前频率、频率、插槽、逻辑处理器、虚拟化、L1缓存指令、L1缓存数据、L2缓存、L3缓存、负载均衡、文件描述符数、进程数、线程数、计算机名等信息。
![](./assets/openkylin系统监视器上新功能啦/1720961153.353785.png)
* 新增内存、交换空间详情页,展示已使用内存、可用内存、共享内存、高速缓存、数据缓存、交换缓存区、活跃的缓冲文件、不活跃的缓冲文件、脏页、映射大小、交换空间大小、可用交换空间、内核数据结构缓存等信息。
![](./assets/openkylin系统监视器上新功能啦/1720961153.354486.png)
* 新增网络历史详情页分别展示各个网卡接收与发送网速波动图、IPv4已连接、IPv6已连接、连接类型、网络名称已连接的WIFI、信号质量已连接的WIFI、信号强度已连接的WIFI、底噪已连接的WIFI、MAC、速率、接收包数量、总计接收、接收错误包、接收丢弃包、接收FIFO、分组帧错误、发送包数量、总计发送、发送错误包、发送丢弃包、发送FIFO、载波损耗等21项信息点击曲线图可切换网卡信息。
![](./assets/openkylin系统监视器上新功能啦/1720961153.3550117.png)
## 三、快捷键
新增两个快捷键功能提高键盘易用性
* 快捷激活搜索框
在系统监视器界面可通过 Ctrl + E 快速激活搜索框
* 快捷激活右键菜单
系统监视器中含有右键菜单的位置,均可在获取焦点后通过 Shift+F10 激活右键菜单
以上就是openKylin系统监视器即将上新的全部功能介绍啦后续将会推出更多的功能以便提高用户对系统资源的管理效率。

View File

@ -0,0 +1,48 @@
**使用国标字体帮助系统迁移**
当大家将应用和文档从Windows等系统直接迁移到openKylin时由于不同系统的字体环境不一致常常出现文字排版效果差异过大的问题。此时需要选用合适的系统字体进行迁移适配找出和原字体在排版方面最相似的系统字体使用这些系统字体来显示迁移的应用和文档。
在openKylin系统中我们添加了中国电子标准化研究院提供的国标系列字库包括宋体黑体仿宋楷体和小标宋五种风格的字体。
如下文所示经我们分析国标系列字体和Windows中对应字体的排版参数较为相似而且支持GB18030-2022标准其中“国标宋体-超大字符集”系列字体完整支持标准中全部汉字,应当作为字体迁移主力。
1. **字体迁移公式**
若能找到和原字体排版相似的系统字体,利用相似字体进行迁移,则能最大程度解决系统迁移时的文字问题。
为此,我们提出了下图所示的字体相似度计算公式,以量化字体迁移时的排版替代效果,从升部降部和前进距离两个方面寻找相似字体。
![descript](./assets/使用国标字体帮助系统迁移/1720961267.9229913.png)
2. **字体迁移分析**
下面以简体汉字“永”繁体汉字“國”为示例从视觉效果和量化数据两个方面分析常用中文字体和Windows指定字体的相似程度。
首先是常用的宋体可以看到从视觉上对比国标宋体就排版而言和Windows宋体最为相似而量化字体参数后进行比较得到的最佳结果同样是是国标宋体。
![descript](./assets/使用国标字体帮助系统迁移/1720961267.9233673.png)
![descript](./assets/使用国标字体帮助系统迁移/1720961267.9235818.jpeg)
仿宋的结果相同,无论在数据还是视觉效果方面,国标仿宋仍然是文档迁移时保证排版一致性的最佳选择。
黑体字体中综合“永”和“國”的显示效果以国标黑体为Windows黑体的最佳迁移选择。
![descript](./assets/使用国标字体帮助系统迁移/1720961267.9239655.png)
![descript](./assets/使用国标字体帮助系统迁移/1720961267.9241471.jpeg)
就华文中宋的视觉效果而言国标小标宋更加相近CESI小标宋整体布局偏高。
![descript](./assets/使用国标字体帮助系统迁移/1720961267.9243476.png)
![descript](./assets/使用国标字体帮助系统迁移/1720961267.9245536.jpeg)
3. **字体迁移总结**
通过以上分析可以看到针对Windows系统的常用字体国标系列字体在简体中文和繁体中文两方面与这些字体都存在较高的相似度。
因此,我们可以得出结论:**国标字体在系统迁移过程中具有较高的使用价值。如果利用国标字体迁移应用和文档,可帮助应用和文档保持较好的排版一致性。**其中openKylin中可以替代Windows常用字体的完整字列表如下图所示。
![descript](./assets/使用国标字体帮助系统迁移/1720961267.9249473.jpeg)

View File

@ -0,0 +1,179 @@
# 基于向量检索技术的UKUI智能语义搜索
# 全局搜索是UKUI桌面环境核心功能之一具备本地文件、文本内容、应用、设置项、便签、图片等聚合搜索功能可以为用户提供快速准确的搜索体验。本期主要介绍UKUI SIG组如何利用向量检索技术实现更加精准、智能的语义模糊搜索提升用户体验。
# 1、背景
## 1.1什么是向量检索?
在深度学习中向量用于对非结构化数据进行特征表述通过使用AI模型对图片文本视频和语音等非结构化数据进行特征向量提取操作然后通过对这些特征向量的计算和检索即可实现对非结构化数据进行分析和检索。
向量的其中一个特性就是可以通过一些距离计算如欧式距离等,来判断向量之间的相似度,即其所代表的元素的相似度。通过对相似度的计算,便可以实现基本的搜索功能。
向量检索的应用场景非常丰富,如推荐系统、图片识别、自然语言处理等。
![descript](./assets/基于向量检索技术的UKUI智能语义搜索/1720961549.1308336.png)
## 1.2为什么要做向量检索?
UKUI中全局搜索应用ukui-search目前的文本内容搜索和图片搜索功能基于传统的中文关键词提取实现图片通过OCR提取文本数据库为基于倒排索引的Xapian数据库搜索基于对“关键词”的搜索实现。从根本上讲搜索还是基于关键词匹配实现即使我们在一定程度上支持了“模糊搜索”即可以在用户输入多个关键词时做部分关键词的匹配即可召回但根本上我们并没有解决用户输入的内容和其搜索内容之间的“模糊”关联关系比如假设用户有很多个描述“天气”的文件包括包含对天气描述的文本文件和天气相关的照片但每个文件中只包含对天气的描述如“阴转小雨”但并不包含“天气“这两个字那么我们现在的搜索功能将不能搜到任何一个文件另外一个例子是如果用户输入的关键词刚好和我们在做关键词提取时提取的不一致那么即使用户输入的内容和文件中的很类似也无法搜索到对应的文件。
而向量搜索是基于“语义”的我们将每个文件中的内容通过特性模型转换成描述他们“语义”的特征向量保存在索引数据库中当用户搜索时我们将用户输入的内容生成向量然后和数据库中的向量通过距离计算返回相似度较高的Topk向量即可实现基于语义的模糊搜索让用户得到的结果更加“人性化”。
# 2、我们要做什么
## 2.1 确定合适的模型
用什么样的模型取决于我们的功能需求和使用场景,比如要实现文本内容搜索,就要使用文本转向量的模型,要实现图片搜索,即需要图片向量的模型,同时,我们还需要注意模型对语言的支持,大部分模型都只支持单一语言。
同时需要根据具体应用场景我们还对模型的性能有一定的要求比如在不支持gpu加速的硬件上如何保证索引的性能和资源占用不至于太高同时模型的大小也决定了我们软件包的打包大小。
如果开源模型难以满足我们的需求,或者我们需要针对用户场景对模型进行定制,那么我们就需要训练自己的模型,但训练模型需要耗费大量的人力物力,就目前来将我们没有足够的资源。
如果开源模型能满足我们的需求,但索引过程中消耗的资源过多,我们可能需要考虑对模型进行一些压缩处理,如模型蒸馏等。
## 2.2 构建数据库
向量搜索其实不一定依赖向量数据库,传统的关系型数据库也可以实现基本的搜索功能,但向量数据库有一些传统数据库无法实现的特性,例如,当平面索引搜索时性能不够时,可以通过分区索引等手段,在保证精度不损失太多的情况下对搜索性能进行优化。
当向量维数很多,且数量也很多时,为了让索引数据库不占用过多磁盘空间,我们还需要考虑对向量数据进行压缩或降维。
同时,考虑到我们的应用场景,数据库还需要支持单条或批量的更新操作。
## 2.3 文件索引与搜索
搞定了模型和数据库接下來要做的就是构建一个基于向量搜索的文件索引服务基于ukui-search的文件索引机制我们可以很方便的实现文件扫描文件监听目录增删数据库管理等操作有了这个基础我们需要实现文件索引数据服务的构建功能并且在UKUI上部署。
在索引数据服务的基础上,我们要实现搜索功能,重点分为两步,第一步是将用户输入的内容转换成向量,第二步是基于向量数据库的搜索接口进行搜索。基于双塔模型,我们可以在一些用户特征数据的分析加入搜索中,比如根据收集的用户习惯做一些搜索结果推荐等。
# 3.我们目前的尝试
我们已经开始尝试使用开源模型进行向量检索技术在UKUI中的应用。针对文本内容搜索我们选用了BERT等自然语言处理模型这些模型可以将文本转换为高维向量。对于图片搜索我们尝试使用了clip模型来提取图片特征。
在数据库方面我们测试了一些针对向量检索的数据库如Faiss和Milvus等。这些数据库提供了丰富的向量检索功能同时支持向量的压缩和降维。在初步测试中我们发现这些数据库在性能和精度方面都表现良好。
为了实现文件索引与搜索功能我们将在ukui-search的基础上进行扩展将文件内容转换为向量并存储在向量数据库中。同时我们对搜索接口进行了调整以支持基于向量相似度的搜索。我们还尝试使用双塔模型结合用户特征数据对搜索结果进行推荐和优化。
目前,我们已经完成了部分功能的原型开发和测试。在实际使用中,基于向量检索的搜索功能相较于传统关键词匹配搜索,确实可以实现更加精准的模糊搜索,提高了用户体验。
## 3.1 文本内容向量搜索
文本内容向量搜索的demo程序使用到了sbert的开源模型和faiss向量数据库。
SBERTSentence-BERT是一种生成句子嵌入表示的深度学习模型其目的是为不同自然语言处理任务提供高质量的文本表示。SBERT模型通过使用双向编码器生成句子嵌入向量以捕获句子中的语义和上下文信息使不同句子之间的相似性得到准确地刻画。
FAISSFacebook AI Similarity Search是一种高性能向量数据库用于处理大规模的向量数据集。FAISS使用一系列的索引结构和近似算法来实现高效的向量搜索。它支持 CPU 和 GPU并可以在内存中存储和检索高维向量。
目前ukui-search中对于中文文本内容的处理使用到了分词将一句话分成多个不同的关键词然后存入倒排索引数据库xapian来提供对应的关键词搜索功能。而向量搜索则可以跳过分词的步骤将整句文本内容作为整体通过sbert模型计算出高维向量存入faiss向量数据库搜索过程中faiss将提供多种索引结构和近似算法来高效输出近似向量相关信息。
## 3.1.1 相似文本内容搜索
使用pandas加载测试文本集作为本地搜索数据。文本内容已做预处理将单个句子作为一行保存。
![descript](./assets/基于向量检索技术的UKUI智能语义搜索/1720961549.1321275.png)
cell运行对应输出
![descript](./assets/基于向量检索技术的UKUI智能语义搜索/1720961549.132531.png)
使用sentence\_transformers加载开源模型然后将测试文本内容输入到模型中获取对应向量。
![descript](./assets/基于向量检索技术的UKUI智能语义搜索/1720961549.1327205.png)
cell运行对应输出
![descript](./assets/基于向量检索技术的UKUI智能语义搜索/1720961549.133024.png)
使用faiss向量数据库将已转换为向量的数据存入索引容器。
![descript](./assets/基于向量检索技术的UKUI智能语义搜索/1720961549.1331973.png)
cell运行对应输出
![descript](./assets/基于向量检索技术的UKUI智能语义搜索/1720961549.1334553.png)
同样使用sentence\_transformers加载开源模型并将要搜索的内容测试数据集中无相同文本内容转换为向量然后使用索引容器搜索近似度前5的数据。
![descript](./assets/基于向量检索技术的UKUI智能语义搜索/1720961549.1336381.png)
cell运行对应输出
![descript](./assets/基于向量检索技术的UKUI智能语义搜索/1720961549.133966.png)
根据搜索结果可以看到向量搜索对于搜索不存在的内容可以输出非常相近的搜索结果。
## 3.1.2 精确文本内容搜索
向量搜索对于存在的内容同样有精确地搜索结果,例如将搜索内容替换为测试文本中存在的:“哈利突然惊醒了”,再进行向量搜索。
![descript](./assets/基于向量检索技术的UKUI智能语义搜索/1720961549.134218.png)
cell运行对应输出
![descript](./assets/基于向量检索技术的UKUI智能语义搜索/1720961549.134522.png)
可以看到对于精确文本内容的搜索faiss向量数据库依然能够提供精确的搜索结果。
## 3.1.3 C++接口技术验证
向量搜索的核心步骤为将文件内容转换为向量的模型和大批量存储向量的向量数据库。目前已实现了使用开源模型中的pytorch模型通过script形式转换为c++可以使用的libtorch类模型为桌面应用实现C++直接调用提供可能。另外使用到了c++为核心编写的faiss向量数据库通过修改部分cmake文件将faiss向量数据库链接到了demo工程中,
仿照之前例子中的搜索流程使用c++编写Transfomer类实现文本通过vocab字典到张量的转换
![descript](./assets/基于向量检索技术的UKUI智能语义搜索/1720961549.1348474.png)
然后加载数据文件并完成向量转换存入数据库:
![descript](./assets/基于向量检索技术的UKUI智能语义搜索/1720961549.1350935.png)
最后将搜索内容转换为向量并通过数据库搜索TOP5的内容
![descript](./assets/基于向量检索技术的UKUI智能语义搜索/1720961549.1353433.png)
程序输出内容如下:
![descript](./assets/基于向量检索技术的UKUI智能语义搜索/1720961549.1356106.png)
对比不同模型使用python的demo程序输出结果与c++版本程序输出结果:
![descript](./assets/基于向量检索技术的UKUI智能语义搜索/1720961549.1357937.png)
![descript](./assets/基于向量检索技术的UKUI智能语义搜索/1720961549.136149.png)
可以看到搜索结果基本一致相似性计算结果也基本一致。最后一个有很小的差异猜测是c++版本使用的libtorch默认精度为float32而python版本的pytorch默认精度为float64导致。
## 3.2 多模态搜索
通过将不同种类的结构化数据通过CLIP模型转换到同一个语义空间中可以实现诸如文字搜图以图搜图等功能大大扩展了桌面搜索的灵活性。语义搜索在单机的部署将领先竞品实现首次发布与应用。
TODO
## 3.3 目前面临的问题
1. 开源模型,自己训练的模型可能更适用
2. GPU适配主机配置各不相同
3. 模型效率问题向量转换速度慢需要模型蒸馏、剪枝等技术优化Intel的CPU可以使用OpenVino加速英伟达GPU可以使用TensorRT加速开源ncnn技术pytorch模型转换为onnx再转换为ncnn模型加载使用
4. 模型占用存储空间大,集成到项目打包受影响
5. 待索引内容选择,图片、文档、视频、语音...涉及多模态模型支持
6. 多模态模型服务化部署服务框架如triton inference server等
# 4.未来计划
1. 继续优化模型和数据库方案,提高搜索效率和准确性。
2. 考虑支持多语言搜索,以满足更广泛的用户需求。
3. 优化搜索结果排序和推荐算法,使搜索结果更加符合用户预期。
4. 针对不同文件类型(如视频和音频),尝试引入相应的特征提取模型,实现全面的多媒体搜索功能。
5. 用户行为预测将UKUI桌面环境各种用户操作向量化通过用户输入内容预测用户行为。
# 5.总结
向量检索技术*在UKUI中的应用有望为用户提供更加智能化、人性化的搜索体验。通过不断优化模型、数据库和搜索算法我们可以为用户提供提供更高效、准确的搜索服务。甚至可以作为整个UKUI桌面环境的统一入口通过输入信息预测用户行为并提供相应“一条龙”式的脚本化操作。*
相关文档:
https://github.com/milvus-io/milvus
https://jina.ai/news/hype-and-hybrids-multimodal-search-means-more-than-keywords-and-vectors-2/
https://github.com/openai/CLIP

View File

@ -0,0 +1,84 @@
# 如何在openkylin上个性化定制开关机动画
开关机动画是openkylin系统的重要组成部分其主要功能是在Linux内核启动的早期遮盖内核打印日志并在内核刷新屏幕分辨率时保证屏幕显示的流畅性。openkylin使用plymouth组件作为开关机动画显示程序。Linux系统在启动时从加载内核到进入登录界面时会进行多次屏幕刷新影响观感plymouth通过内核中对“内核模式设置”Kernel Mode-Setting能够向用户提供一个更加流畅和连续的开关机观感体验。
## plymouth的功能
plymouth支持开关机动画定制通过添加自定义的图片和脚本用户可以使用自己定制的开关机动画实现多样化的开关机体验。同时当需要进行长时间的后台操作如系统安装、备份可以手动执行命令启动plymouth程序显示动画界面实时显示进度等信息同时能够避免在后台操作运行期间用户进行其他操作保证后台操作不受干扰。
## 如何定制自己的开关机动画
### plymouth主题相关内容的存放位置
/usr/share/plymouth/themes/目录下存放了各个主题包的素材以openkylin主题为例下图是/usr/share/plymouth/themes/openkylin下的内容
![descript](./assets/如何在openkylin上制作个性化开关机动画/1720961423.2230046.jpeg)
其中所有的png文件为plymouth动画显示需要的序列帧和显示其他信息所需的素材:
![descript](./assets/如何在openkylin上制作个性化开关机动画/1720961423.2243407.jpeg)
openkylin.plymouth文件记录了openkylin主题所需的图片和脚本的路径如图
![descript](./assets/如何在openkylin上制作个性化开关机动画/1720961423.2249289.jpeg)
openkylin.script为openkylin主题的运行脚本包含了该主题的所有显示逻辑。
### 创建自己的主题目录
创建目录mkdir /usr/share/plymouth/themes/mytheme
### 在新添加的主题目录中添加自己的素材
添加动画所需的png图片创建mytheme.plymouth内容如图
![](./assets/如何在openkylin上制作个性化开关机动画/1720961423.225891.png)创建mytheme.script内容可参考openkylin.script内容。
### 修改配置文件和显示脚本
在mytheme.plymouth中指定/usr/share/plymouth/themes/mytheme为图片存放路径指定/usr/share/plymouth/themes/mytheme.script为显示脚本
根据实际业务需要修改mytheme.script脚本。
### 注册配置文件信息
执行命令:
sudo update-alternatives --install /usr/share/plymouth/themes/default.plymouth default.plymouth /usr/share/plymouth/themes/mytheme/mytheme.plymouth 160
sudo update-alternatives --set default.plymouth /usr/share/plymouth/themes/mytheme/mytheme.plymouth
### 更新initramfs
执行命令:
sudo update-initramfs -u
### 重启系统
重启系统后即可使新的自定义主题生效
### 修改前后对比
修改前的开关机动画:
![](./assets/如何在openkylin上制作个性化开关机动画/1720961423.2269077.jpeg)修改后的关机动画:
![](./assets/如何在openkylin上制作个性化开关机动画/1720961423.2271826.jpeg)## 如何快速修改系统开关机主题
如果需要快速修改系统开关机主题可以直接将自定义的序列帧图片1.png~72.png复制到/usr/share/plymouth/themes/openkylin/下替换原有图片注意自定义图片数量和序号要和原有文件数量和序号一致如果原主题有1.png~100.png共一百张图片则自定义的图片也需要有命名为1.png~100.png的一百张图片然后执行sudo initramfs -u重启后即可使新主题生效。需要说明的是这样修改后旧主题的内容将会被覆盖不能恢复。
## 参考资料
### plymouth官方网站
<https://www.freedesktop.org/wiki/Software/Plymouth/>
### plymouth脚本语法
<https://www.freedesktop.org/wiki/Software/Plymouth/Scripts/>
### plymouth源代码地址
<https://gitlab.freedesktop.org/plymouth/plymouth>

View File

@ -0,0 +1,206 @@
openKylin护眼模式功能和实现原理介绍
## 背景介绍
科学研究揭示在白天蓝光可以增强我们的注意力、反应力和情绪并对自然的睡眠规律起重要作用。然而在晚上蓝光中的高能量具有较强的穿透能力能直接触及视网膜。若长期置身于高强度蓝光的照射下视网膜细胞可能会受到损伤同时它还可能干扰人体内部的生物钟导致睡眠质量的下降。在openKylin开源操作系统中贴心地为用户提供了护眼模式旨在通过调整屏幕色温与亮度降低对用户视力的潜在危害。同时它允许用户根据个人偏好和周围环境的需求灵活调整屏幕显示效果有效屏蔽高能蓝光从而减轻视觉疲劳提升用眼舒适度。
## 如何启动并设置护眼模式
**2.1设置色温**
我们可以通过多种途径快速打开控制面板如按下win+i键、在桌面上右键并选择“显示设置”等。在控制面板的显示设置界面中我们可以找到护眼模式选项。**护眼模式可以减少屏幕的蓝光辐射,以降低对眼睛的刺激。**
![descript](./assets/护眼模式/1720961660.4374223.png)
**相较于单纯的开启色温,全天生硬的使用一个色温值,护眼模式则更加智能、更加贴心。**
在Openkylin2.0的护眼模式中,我们根据人的作息习惯引入了时间段的概念,并针对每个时间段提供不同的色温值,达到略微减少蓝光,中等减少蓝光,大量减少蓝光
三个时间段分别为:
白天:日出之后~日落之前
伴晚日落之后1点之前
深夜1点到3点
黎明3点之后日出之前
每个时间段对应的色温值分别为
白天4500k
伴晚3500k
深夜2800k
黎明3500k
用户在使用电脑的时候系统主动调整屏幕的显示内容是一件不符合用户使用习惯的事情这很令人讨厌为了达到“悄悄的、不知不觉的、让用户无感的”效果。我们效仿的Linux社区的通用做法使用一个小时的时间来进行色温过度每分钟过度六十分之一。例如
白天:日落前一个小时开始向伴晚的色温渐变。
伴晚12点开始向深夜的色温渐变。
深夜2点开始向黎明的色温渐变。
黎明:日出前一个小时向白天的色温渐变。
当然了我们提供的数据仅仅代表我们调研、分析的结论。三个档位的值并非是一个死值他是以Gsettings存储的、可供用户自定义调整的。我们可以通过如下方法设置自己自定义的白天、黑夜让“白天也懂夜的黑”。
查询:
设置:
当然如果设置错误,想要回复可以使用如下命令恢复为预设值
**2.2实现原理**
目前openkylin系统采用的方案是通过调整显示器的gamma曲线来实现调整色温的效果。根据redshift的色温与RGB的对照表将色温以100K为刻度进行拆分每个刻度对应一组RGB的值。举个例子
{
{ 1.**0000**, 0.**0425**, 0.**0000** }, /\* 1000K \*/
{ 1.**0000**, 0.**066**8, 0.**0000** }, /\* 1100K \*/
{ 1.**0000**, 0.0911, 0.**0000** }, /\* 1200K \*/
{ 1.**0000**, 0.1149, 0.**0000** }, /\* ... \*/
/\* ... \*/
{ 1.**0000**, 0.2630, 0.**0062** },/\* 2000K \*/
{ 1.**0000**, 0.4859, 0.1505 },/\* 3000K \*/
{ 1.**0000**, 0.6727, 0.3739 },/\* 4000K \*/
{ 1.**0000**, 0.8250, 0.6272 },/\* 5000K \*/
{ 1.**0000**, 0.9478, 0.8795 },/\* 6000K \*/
{ 1.**0000**, 1.**0000**, 1.**0000** }, /\* 6500K \*/
{ 0.5944, 0.7414, 1.**0000** } /\* 10000K \*/
};
https://gitee.com/openkylin/ukui-settings-daemon/blob/upstream/plugins/gamma-manager/rgb-gamma-table.h
当需要调整色温将色温换算出一组rgb然后根据rgb调整gamma曲线即可此方案不仅可以调整显示的色温同时还可以调整显示器的亮度。
核心代码:
**for**(**int** k = 0; k < m\_pScreenRes->noutput; k++) {
RROutput outputId = m\_pScreenRes->outputs[k];
XRROutputInfo \*outputInfo = XRRGetOutputInfo (QX11Info::display(), m\_pScreenRes, outputId);
QString outputname = QString::fromLatin1(outputInfo->name);
**if** (outputInfo->connection != RR\_Connected) {
XRRFreeOutputInfo(outputInfo);
**continue**;
}
**if** (!outputInfo->crtc) {
ret = true;
USD\_LOG(LOG\_ERR,"crtc size is 0.\n");
**goto** FREEOUTPUT;
}
size = XRRGetCrtcGammaSize(QX11Info::display(), outputInfo->crtc);
**if** (!size) {
ret = false;
USD\_LOG(LOG\_ERR,"Gamma size is 0.\n");
**goto** FREEOUTPUT;
}
/\*
\* The gamma-correction lookup table managed through XRR[GS]etCrtcGamma
\* is 2^n in size, where 'n' is the number of significant bits in
\* the X Color. Because an X Color is 16 bits, size cannot be larger
\* than 2^16.
\*/
**if** (size > 65536) {
ret = false;
USD\_LOG(LOG\_ERR,"Gamma correction table is impossibly large.\n");
**goto** FREEOUTPUT;
}
pCrtcGamma = XRRAllocGamma(size);
**if** (!pCrtcGamma) {
USD\_LOG(LOG\_ERR,"Gamma allocation failed.\n");
**continue**;
}
m\_colorRGB.R == m\_colorRGB.R ? m\_colorRGB.R : **1.0**;
m\_colorRGB.G == m\_colorRGB.G ? m\_colorRGB.G : **1.0**;
m\_colorRGB.B == m\_colorRGB.B ? m\_colorRGB.B : **1.0**;
gammaRed = 1 / m\_colorRGB.R;
gammaGreen = 1 / m\_colorRGB.G;
gammaBlue = 1 / m\_colorRGB.B;
**for** (**int** i = 0; i < size; i++) {\
uint value = (i \* **0xffff**) / (size - 1);
pCrtcGamma->red[i] = value \* m\_colorRGB.R \* brightness;
pCrtcGamma->green[i]= value \* m\_colorRGB.G \* brightness;
pCrtcGamma->blue[i] = value \* m\_colorRGB.B \* brightness;
}
XRRSetCrtcGamma(QX11Info::display(), outputInfo->crtc, pCrtcGamma);
XSync(QX11Info::display(), NULL);
XRRFreeGamma(pCrtcGamma);
FREEOUTPUT:
XRRFreeOutputInfo(outputInfo);
}
3.总结
现在人们的生活中充满了各种光源,包括电脑、手机和照明设备等。不同的人对于光源的接受程度不同,有些人长时间接触光源而不会对视力产生影响,而有些人则相反。其实,色温只是决定光线特性的一个方面,流明也是需要考虑的重要因素。为了保护视力,除了选择合适的色温和流明,培养远眺的习惯和让眼部肌肉放松也是很重要的。
openKylin操作系统中的护眼模式是一项既实用又方便的功能它通过科学合理地调整屏幕色彩减轻长时间使用电脑对眼睛可能造成的负担。同时用户还可以根据自己的日常作息和视觉感受进行个性化设置从而更好地保护视力。

View File

@ -2,8 +2,6 @@
## 1. 文档仓库介绍
openKylin文档仓库托管在Gitee上仓库地址为https://gitee.com/openkylin/docs
文档FAQ分支https://gitee.com/openkylin/docs/tree/dev-faq/
## 2. 文档贡献流程
@ -91,32 +89,6 @@ git push origin new_branch_name
### 3.2 文档内容
请遵循以下规范:
- 简洁明了,易于理解,必要时需要使用复杂的术语和概念,避免使用过于复杂的语法和逻辑。
- 面向普通用户的文档建议从用户的角度出发,以使用场景为案例,解决问题优先,避免只讲概念和技术知识。
- 文档内容要准确无误,技术上实事求是,避免使用夸张和误导性的语言。
- 要符合实际使用需求,应该以成熟稳定的技术和方法为主,避免使用过时的技术和方法,避免使用未经测试和验证的技术。
- 提交的文档不应该包含个人隐私信息,侵犯知识产权,违反法律法规的内容。
- 内容方向没有特殊要求只要可以在openKylin上使用即可。
- 内容需要照顾到新手用户,所有的流程都要尽可能详细。
- 内容需要有标题、作者和创建时间,其它要求暂无。
- 禁止带有侮辱性词汇,禁止政治敏感词汇。
- 禁止发布广告。
- 文件名及分类文件夹尽可能言简意赅。
- 结尾统一用.md的后缀编码为统一的无BOM头的UTF-8。
- 图片等资源统一放置在和文档同级的资源目录并分类。
- 图片高度建议在640px左右、宽度不超过820px、图片一般为.png格式大小不超过150K。
- 为避免产权侵犯,引起纠纷,文档配图请使用原创图片或无版权图片。
- 图片建议根据内容命名,只用数字序列不利于后续图片的继承。
- 禁止任何分支强制推送。
- 主分支不接受除dev分支以外的任何pr请求同时也不接受任何推送。
- 主仓库的英文版建议放到en对应的目录SIG组成员会有专人去进行审核。
- 如果路径有空格则全部用下划线隔开。
- 翻译类的文档整篇翻译的不接受轻量级pr只能选择fork以后的pr改动不多的可以接受轻量级pr。
- 建议跳转链接在仓库内使用相对路径除非链接是仓库之外的尽量避免http开头的绝对路径。
## 4. FAQ文档规范
FAQ文档是openKylin社区常见问题解答文档用于回答用户在使用openKylin过程中遇到的问题。

View File

@ -43,7 +43,7 @@ openKylin社区docs sig致力于完善openKylin社区文档帮助用户更
[docs](https://gitee.com/openkylin/docs)
[FAQ文档规范](./04_社区贡献/FAQ文档贡献指南.md)
手机用户因为码云的自适应问题默认看到的是README文件仓库具体内容访问此链接[手机端仓库目录](https://gitee.com/openkylin/docs/tree/master)
@ -66,6 +66,11 @@ openKylin社区docs sig致力于完善openKylin社区文档帮助用户更
# 文档贡献指南
## 内容要求
- 简洁明了,易于理解,必要时需要使用复杂的术语和概念,避免使用过于复杂的语法和逻辑。
- 面向普通用户的文档建议从用户的角度出发,以使用场景为案例,解决问题优先,避免只讲概念和技术知识。
- 文档内容要准确无误,技术上实事求是,避免使用夸张和误导性的语言。
- 要符合实际使用需求,应该以成熟稳定的技术和方法为主,避免使用过时的技术和方法,避免使用未经测试和验证的技术。
- 提交的文档不应该包含个人隐私信息,侵犯知识产权,违反法律法规的内容。
- 内容方向没有特殊要求只要可以在openKylin上使用即可
- 内容需要照顾到新手用户,所有的流程都要尽可能详细
- 内容需要有标题、作者和创建时间,其它要求暂无