After Width: | Height: | Size: 37 KiB |
After Width: | Height: | Size: 21 KiB |
After Width: | Height: | Size: 188 KiB |
After Width: | Height: | Size: 168 KiB |
After Width: | Height: | Size: 122 KiB |
After Width: | Height: | Size: 49 KiB |
After Width: | Height: | Size: 54 KiB |
After Width: | Height: | Size: 25 KiB |
After Width: | Height: | Size: 39 KiB |
After Width: | Height: | Size: 22 KiB |
After Width: | Height: | Size: 58 KiB |
After Width: | Height: | Size: 18 KiB |
After Width: | Height: | Size: 36 KiB |
After Width: | Height: | Size: 107 KiB |
After Width: | Height: | Size: 63 KiB |
After Width: | Height: | Size: 15 KiB |
After Width: | Height: | Size: 103 KiB |
After Width: | Height: | Size: 5.9 KiB |
After Width: | Height: | Size: 67 KiB |
After Width: | Height: | Size: 14 KiB |
After Width: | Height: | Size: 109 KiB |
After Width: | Height: | Size: 14 KiB |
After Width: | Height: | Size: 108 KiB |
After Width: | Height: | Size: 17 KiB |
After Width: | Height: | Size: 60 KiB |
After Width: | Height: | Size: 57 KiB |
After Width: | Height: | Size: 79 KiB |
After Width: | Height: | Size: 15 KiB |
After Width: | Height: | Size: 162 KiB |
After Width: | Height: | Size: 62 KiB |
After Width: | Height: | Size: 519 KiB |
After Width: | Height: | Size: 202 KiB |
After Width: | Height: | Size: 386 KiB |
After Width: | Height: | Size: 25 KiB |
After Width: | Height: | Size: 17 KiB |
After Width: | Height: | Size: 20 KiB |
After Width: | Height: | Size: 405 KiB |
|
@ -0,0 +1,44 @@
|
|||
# openkylin 2.0 系统监视器上新功能啦!
|
||||
|
||||
openKylin系统监视器是一款面向openKylin操作系统用户的桌面应用,它满足了用户对于各种系统资源的监控和管理。在前面章节中,我们为大家讲解介绍了openKylin系统监视器的功能作用,包括处理器、交换空间、网络、磁盘、进程和服务等。今天我们就来讲一讲它即将在openKylin 2.0版本上新的那些好用功能。
|
||||
|
||||
## 一、最小化到托盘显示
|
||||
|
||||
以前大家点击右上角的“X”按钮,系统监视器将直接退出;现在UKUI SIG增加了最小化到托盘显示的功能,点击右上角的“X”按钮会在任务栏显示一个系统监视器图标,将鼠标悬浮上去可显示CPU占用率、网络上传与下载速率、内存占用率、磁盘占用率。
|
||||
|
||||

|
||||
|
||||
鼠标右键菜单可退出系统监视器或激活系统监视器窗口,鼠标左键单击激活系统监视器窗口。
|
||||
|
||||

|
||||
|
||||
## 二、处理器、内存、网络历史等详情页显示
|
||||
|
||||
openKylin系统监视器新增处理器、内存、网络历史三个模块的详情显示界面,可以通过点击主界面左侧的处理器、内存、网络历史模块,在主界面右边进行详情显示,并可以通过点击右上角的“隐藏详情”按钮返回进程页面。
|
||||
|
||||
* 新增处理器详情页展示处理器总利用率、当前频率、频率、插槽、逻辑处理器、虚拟化、L1缓存(指令)、L1缓存(数据)、L2缓存、L3缓存、负载均衡、文件描述符数、进程数、线程数、计算机名等信息。
|
||||
|
||||

|
||||
|
||||
* 新增内存、交换空间详情页,展示已使用内存、可用内存、共享内存、高速缓存、数据缓存、交换缓存区、活跃的缓冲文件、不活跃的缓冲文件、脏页、映射大小、交换空间大小、可用交换空间、内核数据结构缓存等信息。
|
||||
|
||||

|
||||
|
||||
* 新增网络历史详情页,分别展示各个网卡接收与发送网速波动图、IPv4(已连接)、IPv6(已连接)、连接类型、网络名称(已连接的WIFI)、信号质量(已连接的WIFI)、信号强度(已连接的WIFI)、底噪(已连接的WIFI)、MAC、速率、接收包数量、总计接收、接收(错误包)、接收(丢弃包)、接收FIFO、分组帧错误、发送包数量、总计发送、发送(错误包)、发送(丢弃包)、发送FIFO、载波损耗等21项信息,点击曲线图可切换网卡信息。
|
||||
|
||||

|
||||
|
||||
## 三、快捷键
|
||||
|
||||
新增两个快捷键功能提高键盘易用性
|
||||
|
||||
* 快捷激活搜索框
|
||||
|
||||
在系统监视器界面可通过 Ctrl + E 快速激活搜索框
|
||||
|
||||
* 快捷激活右键菜单
|
||||
|
||||
系统监视器中含有右键菜单的位置,均可在获取焦点后通过 Shift+F10 激活右键菜单
|
||||
|
||||
以上就是openKylin系统监视器即将上新的全部功能介绍啦,后续将会推出更多的功能,以便提高用户对系统资源的管理效率。
|
||||
|
|
@ -0,0 +1,48 @@
|
|||
**使用国标字体帮助系统迁移**
|
||||
|
||||
当大家将应用和文档从Windows等系统直接迁移到openKylin时,由于不同系统的字体环境不一致,常常出现文字排版效果差异过大的问题。此时需要选用合适的系统字体进行迁移适配,找出和原字体在排版方面最相似的系统字体,使用这些系统字体来显示迁移的应用和文档。
|
||||
|
||||
在openKylin系统中,我们添加了中国电子标准化研究院提供的国标系列字库,包括宋体,黑体,仿宋,楷体和小标宋五种风格的字体。
|
||||
|
||||
如下文所示,经我们分析,国标系列字体和Windows中对应字体的排版参数较为相似,而且支持GB18030-2022标准,其中“国标宋体-超大字符集”系列字体完整支持标准中全部汉字,应当作为字体迁移主力。
|
||||
|
||||
1. **字体迁移公式**
|
||||
|
||||
若能找到和原字体排版相似的系统字体,利用相似字体进行迁移,则能最大程度解决系统迁移时的文字问题。
|
||||
|
||||
为此,我们提出了下图所示的字体相似度计算公式,以量化字体迁移时的排版替代效果,从升部降部和前进距离两个方面寻找相似字体。
|
||||
|
||||

|
||||
|
||||
2. **字体迁移分析**
|
||||
|
||||
下面以简体汉字“永”,繁体汉字“國”为示例,从视觉效果和量化数据两个方面分析常用中文字体和Windows指定字体的相似程度。
|
||||
|
||||
首先是常用的宋体,可以看到从视觉上对比,国标宋体就排版而言和Windows宋体最为相似;而量化字体参数后进行比较,得到的最佳结果同样是是国标宋体。
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
仿宋的结果相同,无论在数据还是视觉效果方面,国标仿宋仍然是文档迁移时保证排版一致性的最佳选择。
|
||||
|
||||
黑体字体中,综合“永”和“國”的显示效果,以国标黑体为Windows黑体的最佳迁移选择。
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
就华文中宋的视觉效果而言,国标小标宋更加相近,CESI小标宋整体布局偏高。
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
3. **字体迁移总结**
|
||||
|
||||
通过以上分析可以看到,针对Windows系统的常用字体,国标系列字体在简体中文和繁体中文两方面与这些字体都存在较高的相似度。
|
||||
|
||||
因此,我们可以得出结论:**国标字体在系统迁移过程中具有较高的使用价值。如果利用国标字体迁移应用和文档,可帮助应用和文档保持较好的排版一致性。**其中,openKylin中可以替代Windows常用字体的完整字列表如下图所示。
|
||||
|
||||

|
||||
|
|
@ -0,0 +1,179 @@
|
|||
# 基于向量检索技术的UKUI智能语义搜索
|
||||
|
||||
# 全局搜索是UKUI桌面环境核心功能之一,具备本地文件、文本内容、应用、设置项、便签、图片等聚合搜索功能,可以为用户提供快速准确的搜索体验。本期主要介绍UKUI SIG组如何利用向量检索技术实现更加精准、智能的语义模糊搜索,提升用户体验。
|
||||
|
||||
# 1、背景
|
||||
|
||||
## 1.1什么是向量检索?
|
||||
|
||||
在深度学习中,向量用于对非结构化数据进行特征表述,通过使用AI模型对图片,文本,视频和语音等非结构化数据进行特征向量提取操作,然后通过对这些特征向量的计算和检索,即可实现对非结构化数据进行分析和检索。
|
||||
|
||||
向量的其中一个特性就是可以通过一些距离计算如欧式距离等,来判断向量之间的相似度,即其所代表的元素的相似度。通过对相似度的计算,便可以实现基本的搜索功能。
|
||||
|
||||
向量检索的应用场景非常丰富,如推荐系统、图片识别、自然语言处理等。
|
||||
|
||||

|
||||
|
||||
## 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向量数据库。
|
||||
|
||||
SBERT(Sentence-BERT)是一种生成句子嵌入表示的深度学习模型,其目的是为不同自然语言处理任务提供高质量的文本表示。SBERT模型通过使用双向编码器生成句子嵌入向量,以捕获句子中的语义和上下文信息,使不同句子之间的相似性得到准确地刻画。
|
||||
|
||||
FAISS(Facebook AI Similarity Search)是一种高性能向量数据库,用于处理大规模的向量数据集。FAISS使用一系列的索引结构和近似算法来实现高效的向量搜索。它支持 CPU 和 GPU,并可以在内存中存储和检索高维向量。
|
||||
|
||||
目前ukui-search中对于中文文本内容的处理使用到了分词,将一句话分成多个不同的关键词然后存入倒排索引数据库xapian来提供对应的关键词搜索功能。而向量搜索则可以跳过分词的步骤将整句文本内容作为整体通过sbert模型计算出高维向量存入faiss向量数据库,搜索过程中faiss将提供多种索引结构和近似算法来高效输出近似向量相关信息。
|
||||
|
||||
## 3.1.1 相似文本内容搜索
|
||||
|
||||
使用pandas加载测试文本集作为本地搜索数据。文本内容已做预处理,将单个句子作为一行保存。
|
||||
|
||||

|
||||
|
||||
cell运行对应输出:
|
||||
|
||||

|
||||
|
||||
使用sentence\_transformers加载开源模型,然后将测试文本内容输入到模型中获取对应向量。
|
||||
|
||||

|
||||
|
||||
cell运行对应输出:
|
||||
|
||||

|
||||
|
||||
使用faiss向量数据库将已转换为向量的数据存入索引容器。
|
||||
|
||||

|
||||
|
||||
cell运行对应输出:
|
||||
|
||||

|
||||
|
||||
同样使用sentence\_transformers加载开源模型并将要搜索的内容(测试数据集中无相同文本内容)转换为向量,然后使用索引容器搜索近似度前5的数据。
|
||||
|
||||

|
||||
|
||||
cell运行对应输出:
|
||||
|
||||

|
||||
|
||||
根据搜索结果可以看到向量搜索对于搜索不存在的内容可以输出非常相近的搜索结果。
|
||||
|
||||
## 3.1.2 精确文本内容搜索
|
||||
|
||||
向量搜索对于存在的内容同样有精确地搜索结果,例如将搜索内容替换为测试文本中存在的:“哈利突然惊醒了”,再进行向量搜索。
|
||||
|
||||

|
||||
|
||||
cell运行对应输出:
|
||||
|
||||

|
||||
|
||||
可以看到对于精确文本内容的搜索faiss向量数据库依然能够提供精确的搜索结果。
|
||||
|
||||
## 3.1.3 C++接口技术验证
|
||||
|
||||
向量搜索的核心步骤为将文件内容转换为向量的模型和大批量存储向量的向量数据库。目前已实现了使用开源模型中的pytorch模型通过script形式转换为c++可以使用的libtorch类模型,为桌面应用实现C++直接调用提供可能。另外使用到了c++为核心编写的faiss向量数据库,通过修改部分cmake文件将faiss向量数据库链接到了demo工程中,
|
||||
|
||||
仿照之前例子中的搜索流程,使用c++编写Transfomer类实现文本通过vocab字典到张量的转换:
|
||||
|
||||

|
||||
|
||||
然后加载数据文件并完成向量转换存入数据库:
|
||||
|
||||

|
||||
|
||||
最后将搜索内容转换为向量并通过数据库搜索TOP5的内容:
|
||||
|
||||

|
||||
|
||||
程序输出内容如下:
|
||||
|
||||

|
||||
|
||||
对比不同模型使用python的demo程序输出结果与c++版本程序输出结果:
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
可以看到搜索结果基本一致,相似性计算结果也基本一致。最后一个有很小的差异猜测是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
|
||||
|
|
@ -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下的内容:
|
||||
|
||||

|
||||
|
||||
其中,所有的png文件为plymouth动画显示需要的序列帧和显示其他信息所需的素材:
|
||||
|
||||

|
||||
|
||||
openkylin.plymouth文件记录了openkylin主题所需的图片和脚本的路径,如图:
|
||||
|
||||

|
||||
|
||||
openkylin.script为openkylin主题的运行脚本,包含了该主题的所有显示逻辑。
|
||||
|
||||
### 创建自己的主题目录
|
||||
|
||||
创建目录:mkdir /usr/share/plymouth/themes/mytheme
|
||||
|
||||
### 在新添加的主题目录中添加自己的素材
|
||||
|
||||
添加动画所需的png图片,创建mytheme.plymouth,内容如图:
|
||||
|
||||
创建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
|
||||
|
||||
### 重启系统
|
||||
|
||||
重启系统后即可使新的自定义主题生效
|
||||
|
||||
### 修改前后对比
|
||||
|
||||
修改前的开关机动画:
|
||||
|
||||
修改后的关机动画:
|
||||
|
||||
## 如何快速修改系统开关机主题
|
||||
|
||||
如果需要快速修改系统开关机主题,可以直接将自定义的序列帧图片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>
|
||||
|
|
@ -0,0 +1,206 @@
|
|||
openKylin护眼模式功能和实现原理介绍
|
||||
|
||||
## 背景介绍
|
||||
|
||||
科学研究揭示,在白天,蓝光可以增强我们的注意力、反应力和情绪,并对自然的睡眠规律起重要作用。然而,在晚上,蓝光中的高能量具有较强的穿透能力,能直接触及视网膜。若长期置身于高强度蓝光的照射下,视网膜细胞可能会受到损伤,同时,它还可能干扰人体内部的生物钟,导致睡眠质量的下降。在openKylin开源操作系统中,贴心地为用户提供了护眼模式,旨在通过调整屏幕色温与亮度,降低对用户视力的潜在危害。同时,它允许用户根据个人偏好和周围环境的需求,灵活调整屏幕显示效果,有效屏蔽高能蓝光,从而减轻视觉疲劳,提升用眼舒适度。
|
||||
|
||||
## 如何启动并设置护眼模式
|
||||
|
||||
**2.1设置色温**
|
||||
|
||||
我们可以通过多种途径快速打开控制面板,如按下win+i键、在桌面上右键并选择“显示设置”等。在控制面板的显示设置界面中,我们可以找到护眼模式选项。**护眼模式可以减少屏幕的蓝光辐射,以降低对眼睛的刺激。**
|
||||
|
||||

|
||||
|
||||
**相较于单纯的开启色温,全天生硬的使用一个色温值,护眼模式则更加智能、更加贴心。**
|
||||
|
||||
在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操作系统中的护眼模式是一项既实用又方便的功能,它通过科学合理地调整屏幕色彩,减轻长时间使用电脑对眼睛可能造成的负担。同时,用户还可以根据自己的日常作息和视觉感受进行个性化设置,从而更好地保护视力。
|
||||
|
|
@ -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过程中遇到的问题。
|
7
home.md
|
@ -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上使用即可
|
||||
- 内容需要照顾到新手用户,所有的流程都要尽可能详细
|
||||
- 内容需要有标题、作者和创建时间,其它要求暂无
|
||||
|
|